News for hackers. Stuff that matters.

A comment on The Imposter's Handbook. Parent comment

Re:The Imposter's Handbook by riskable on Wednesday August 24, 2016 @11:22AM (#12352681)
What's funny about your example is that using a set in that situation would be an example of premature optimization. If your entire list of receipts fits into memory users won't notice a difference between a list and a set.

Also, if you used a list in Python (or other similar dynamic languages) swapping a list out for a set is a trivial operation...

    receipts = []
    # ...becomes:
    receipts = set()
...and it would require no changes to the conditional logic of the application. So later, if it turns out you're having performance issues you (usually) make a few minor changes here and there and get your 10x or 100x or even 10,000x speedup.
[ Parent | on HN ]
Re:The Imposter's Handbook by scott_s on Wednesday August 24, 2016 @11:32AM (#12352759)
> If your entire list of receipts fits into memory users won't notice a difference between a list and a set.

If you had said "small enough", I would agree, but linear walks of data that can fit in memory can easily be noticed by users, for large enough lists. (Very large lists can fit in memory.)

But, at a higher level, yes, this is always true when people talk about performance: make sure what you're optimizing actually matters. I think a charitable reading of what ThePawnBreak said should assume one has already determined this particular operation matters for performance.

[ Parent | on HN ]
Re:The Imposter's Handbook by pjc50 on Wednesday August 24, 2016 @12:07PM (#12353016)
Earlier this month I was looking at the question of "why does it take 160ms to scan a list of just 60,000 items?

The answer turned out to be "because they're not adjacent and on this embedded system every single cache miss costs you hundreds of nanoseconds".

I strongly agree that, like woodworkers, performance improvers should measure before they take out the power tools.

[ Parent | on HN ]
Re:The Imposter's Handbook by emodendroket on Wednesday August 24, 2016 @12:24PM (#12353161)
> What's funny about your example is that using a set in that situation would be an example of premature optimization. If your entire list of receipts fits into memory users won't notice a difference between a list and a set.

That's completely untrue if you're running this check often enough.

[ Parent | on HN ]
Re:The Imposter's Handbook by kchoudhu on Wednesday August 24, 2016 @11:45AM (#12352855)
Not to mention that most of the kids today would have stowed their entire population of receipts in whatever the datastore flavor-of-the-week is. At that point, the lookup would effectively be a SELECT -- which the DBMS would optimize away for you.
[ Parent | on HN ]
Re:The Imposter's Handbook by pjc50 on Wednesday August 24, 2016 @12:12PM (#12353065)
.. unless they've forgotten the index, at which point the DBMS grinds to a halt.

Or they've written the query on the wrong side of the ORM so it has to pull in all the objects, check the value, and discard them.

[ Parent | on HN ]
Re:The Imposter's Handbook by emodendroket on Wednesday August 24, 2016 @03:26PM (#12354567)
A very simple example that I think is "real-world" enough is recursively descending the fields of some object which has cycles. If you use a list instead of a set this can be quite slow.
[ Parent | on HN ]