6 ms·
That repo encourages mindless microoptimization. Don't waste your time worrying how to iterate a slice. Most of the time it makes no difference.
by lmb 8y ago
That repo encourages mindless microoptimization. Don't waste your time worrying how to iterate a slice. Most of the time it makes no difference.
- w8rbt 8y agoYes, but it's always fun to go faster ;)
- notheguyouthink 8y agoMost of the time it doesn't except for when it does. Your statement is overreaching and is a micro optimization in and of itself. Valuing to ignore understanding when it is important to optimize in this manner, and when it isn't. The author's use case is very beneficial to optimize in this manner.
- dronescanfly 8y agoYour assessment of the situation encourages mindless ignoring of optimization. It always depends on the situation. Stuff that is done once in a moon... idc as long as it's reasonably fast. For stuff that's on the hot path you sometimes have to pull up your sleeves and optimize where possible. At work I just had to implement a heap just because the heap provided by the standard libs wasn't fitting our problem. Please don't discourage people creating this kind of content. It matters to far more people than you might have in mind.
- wmsiler 8y agoThat repo doesn't encourage anything. It's presenting data that the author found useful for another project they were working on, which presumably did benefit from micro-optimization. You are right that micro-optimization is usually not needed, but the repo and its author never claimed otherwise.
- tapirl 8y agoThere are several slcie iteration ways in Go. They do have some performance differences, depending on the element types of slices. Please view the example in the end of the article for details: https://go101.org/article/value-copy-cost.html https://go101.org/article/value-copy-cost.html