3 ms·

It's the usual premature optimisation problem. I'd personally go with whichever data structure makes your code easy to write and comprehend, then profile, then

It's the usual premature optimisation problem. I'd personally go with whichever data structure makes your code easy to write and comprehend, then profile, then adjust as necessary. 99% of code doesn't need to be efficient, but the maintenance cost tends to relate to the sheer amount of code and it's comprehensibility, and this cost is the one to optimise for, not speed. For the other 1% that you identify with profilers, go with the more optimal data structure, and accept the reduction in clarity and purpose.

kaba0 4y ago
I would wager that getting big O complexity right is absolutely not premature optimizations, it is perhaps the only thing one should “optimize” upfront. The very first, biggest impact performance metric is the algorithm used — anything besides that will be meaningless given a bad algorithm.
- lazide 4y ago
  As with anything ‘it depends’ - if you’re writing CRUD enterprise code that at most will see several hundred objects at a time, but will have to be understood by 100s of cut rate contractors over it’s lifetime? Go for obvious and hard to screw up, over the most efficient algorithm. Of course someone will misappropriate it and use it as the core of some terribly thought out data handling app with billions of items, but at least anyone with a clue will be able to figure out why it’s terrible later. And if no one with a clue is around, then not like there was any better outcome going to happen except by sheer luck anyway.
  - cesaref 4y ago
    Right, and my point is that maintenance is a massive cost which is boring, and often overlooked when talking about the 'cost' of code. Slow code causing excessive CPU load or requiring multiple application servers is one cost, but maintenance is another, and the skill is to understand when it's appropriate for what. My default would be to generate maintainable code first, and worry about performance when it matters, but a knee-jerk 'linked lists are slow so avoid' approach is almost always the wrong way of approaching it. Choose the correct data structure and algorithm for maintainability, then optimise if it's too slow should be the default in my opinion.
- cesaref 4y ago
  Sure, but this article is comparing two data structures which have the same big O complexity for the operation, O(N), and the comparison is about the relative performance of the two. My point is that worrying about this for a code path that only happens once at startup is silly, but in the main loop of a critical performance code path, then sure, go ahead. The mistake would be to use vectors all over the place instead of lists 'because linked lists are slow' when they have other benefits (e.g. cost of insertion, address of elements don't change etc) which may adversely affect the readability of the surrounding code if you by default use vectors. Anyhow, just my opinion of course.

kaba0 4y ago

I would wager that getting big O complexity right is absolutely not premature optimizations, it is perhaps the only thing one should “optimize” upfront. The very first, biggest impact performance metric is the algorithm used — anything besides that will be meaningless given a bad algorithm.

lazide 4y ago
As with anything ‘it depends’ - if you’re writing CRUD enterprise code that at most will see several hundred objects at a time, but will have to be understood by 100s of cut rate contractors over it’s lifetime? Go for obvious and hard to screw up, over the most efficient algorithm. Of course someone will misappropriate it and use it as the core of some terribly thought out data handling app with billions of items, but at least anyone with a clue will be able to figure out why it’s terrible later. And if no one with a clue is around, then not like there was any better outcome going to happen except by sheer luck anyway.
- cesaref 4y ago
  Right, and my point is that maintenance is a massive cost which is boring, and often overlooked when talking about the 'cost' of code. Slow code causing excessive CPU load or requiring multiple application servers is one cost, but maintenance is another, and the skill is to understand when it's appropriate for what. My default would be to generate maintainable code first, and worry about performance when it matters, but a knee-jerk 'linked lists are slow so avoid' approach is almost always the wrong way of approaching it. Choose the correct data structure and algorithm for maintainability, then optimise if it's too slow should be the default in my opinion.
cesaref 4y ago
Sure, but this article is comparing two data structures which have the same big O complexity for the operation, O(N), and the comparison is about the relative performance of the two. My point is that worrying about this for a code path that only happens once at startup is silly, but in the main loop of a critical performance code path, then sure, go ahead. The mistake would be to use vectors all over the place instead of lists 'because linked lists are slow' when they have other benefits (e.g. cost of insertion, address of elements don't change etc) which may adversely affect the readability of the surrounding code if you by default use vectors. Anyhow, just my opinion of course.