6 ms·

Do you want to claim you've never written quick and ugly code to get something working to come back and fix it up later? Pretty much everyone I know will throw

Do you want to claim you've never written quick and ugly code to get something working to come back and fix it up later? Pretty much everyone I know will throw down an O(n^2) algorithm or whatever in their first pass and replace it with something more thought out once they have the time to think deeply about it. If you're fretting about optimization at every stage of development, you're really doing it wrong. This is precisely the type of early optimization that everyone and their dog will tell you is bad. You should focus first on making your program work and laying out the logic and data flows. Optimization does not matter until the program is almost finished.

tough 1y ago
One could even say optimization does not matter until the program is already running.
deleted 1y ago
[deleted]
deleted 1y ago
[deleted]
9rx 1y ago
Purposefully introducing underperforming code as a tradeoff to meet some other goal (faster delivery, for example) is something else entirely. It doesn't require intuition or profiling – at most requiring only memory of the choice. A fun aside, but not related to what we're talking about.
patrick451 1y ago
This only works if you don't need real time performance. For anything that does need to run in realtime, you have to be damn sure that whatever your initial approach is can be optimized to run at the required sample rate. Otherwise, you will be ripping out the entire design and starting over. You might as well optimize first.
cogman10 1y ago
> Pretty much everyone I know will throw down an O(n^2) algorithm or whatever in their first pass and replace it with something more thought out once they have the time to think deeply about it. Most of the times I've seen this, the faster algorithm is literally just a dictionary with a well-defined key. I honestly do not understand why that's not the first solution most devs think of and why n^2 seems to dominate. As an example, I've seen code like this quiet a bit result = [] for (item: items) { for (item2: items) { if (item != item2 && item.foo == item2.foo) { result.add(item) } } } Easily replaced and massively easier to read as result = [] itemFoo = HashSet() for (item: items) { if (itemFoo.contains(item.foo)) result.add(item) else itemFoo.add(item.foo) } The mindset of re-looking for values in a collection you are already iterating through is just foreign to me. The first solution for something like this in my mind is always utilizing dictionaries.
- YZF 1y ago
  For many people performance optimization really starts with your second version. I'm not even sure what this is supposed to do exactly but the O(N^2) is just bad/sloppy code. Optimization is usually more about getting the right algorithms to execute faster. At least that's how I think about it.
  - cogman10 1y ago
    Yet, as you'll see in this thread at least 1 other commentor is arguing that option 1 is better. What you and I see as bad/sloppy code, they see as the ideal starting point. A pretty common attitude that I've ran into. People take the "premature optimization" quote to mean "Never think about big oh when writing code".
    - 9rx 1y ago
      Beware of microbenchmarks, but at least on my machine under the specific circumstances I ran it under, the double loop algorithm is about two times faster than the hash map algorithm while n < 100. That might not mean much if you spend your days working with large datasets, but in my day-to-day datasets with 100 entires or less is the norm. Readability is subjective, but at least from a performance perspective it is a reasonable starting point unless you know upfront that you are going to be working with large datasets – but in that case the optimization isn't premature, is it?

tough 1y ago

One could even say optimization does not matter until the program is already running.

deleted 1y ago

[deleted]

deleted 1y ago

[deleted]

9rx 1y ago

Purposefully introducing underperforming code as a tradeoff to meet some other goal (faster delivery, for example) is something else entirely. It doesn't require intuition or profiling – at most requiring only memory of the choice. A fun aside, but not related to what we're talking about.

patrick451 1y ago

This only works if you don't need real time performance. For anything that does need to run in realtime, you have to be damn sure that whatever your initial approach is can be optimized to run at the required sample rate. Otherwise, you will be ripping out the entire design and starting over. You might as well optimize first.

cogman10 1y ago

> Pretty much everyone I know will throw down an O(n^2) algorithm or whatever in their first pass and replace it with something more thought out once they have the time to think deeply about it. Most of the times I've seen this, the faster algorithm is literally just a dictionary with a well-defined key. I honestly do not understand why that's not the first solution most devs think of and why n^2 seems to dominate. As an example, I've seen code like this quiet a bit result = [] for (item: items) { for (item2: items) { if (item != item2 && item.foo == item2.foo) { result.add(item) } } } Easily replaced and massively easier to read as result = [] itemFoo = HashSet() for (item: items) { if (itemFoo.contains(item.foo)) result.add(item) else itemFoo.add(item.foo) } The mindset of re-looking for values in a collection you are already iterating through is just foreign to me. The first solution for something like this in my mind is always utilizing dictionaries.

YZF 1y ago
For many people performance optimization really starts with your second version. I'm not even sure what this is supposed to do exactly but the O(N^2) is just bad/sloppy code. Optimization is usually more about getting the right algorithms to execute faster. At least that's how I think about it.
- cogman10 1y ago
  Yet, as you'll see in this thread at least 1 other commentor is arguing that option 1 is better. What you and I see as bad/sloppy code, they see as the ideal starting point. A pretty common attitude that I've ran into. People take the "premature optimization" quote to mean "Never think about big oh when writing code".
  - 9rx 1y ago
    Beware of microbenchmarks, but at least on my machine under the specific circumstances I ran it under, the double loop algorithm is about two times faster than the hash map algorithm while n < 100. That might not mean much if you spend your days working with large datasets, but in my day-to-day datasets with 100 entires or less is the norm. Readability is subjective, but at least from a performance perspective it is a reasonable starting point unless you know upfront that you are going to be working with large datasets – but in that case the optimization isn't premature, is it?