3 ms·

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

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.

kchoudhu 10y ago
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.
- pjc50 10y ago
  .. 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.
- emodendroket 10y ago
  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.
scott_s 10y ago
> 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.
- pjc50 10y ago
  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.
emodendroket 10y ago
> 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.
deleted 10y ago
[deleted]

kchoudhu 10y ago

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.

pjc50 10y ago
.. 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.
emodendroket 10y ago
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.

scott_s 10y ago

> 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.

pjc50 10y ago
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.

emodendroket 10y ago

> 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.

deleted 10y ago

[deleted]