3 ms·
Great article. I was recently optimizing a go program. I was focusing on trying to improve the underlying algorithms, but then I realized after profiling that m
by defertoreptar 8y ago
Great article. I was recently optimizing a go program. I was focusing on trying to improve the underlying algorithms, but then I realized after profiling that most of the time was spent creating temporary slices (many, many times). When I changed it to reuse existing slices, I saw a bigger performance gain than all the other effort combined.
- weberc2 8y agoYeah, this is usually what I run into. I once had a recursive algorithm to collect a flat list of nodes in a tree. I found that building slices was the bottleneck, so I changed the signature to `func (t Tree) CountNodes() int` and `func (t Tree) Nodes(outSlice []Node)`, and then I'd call it like: nodes := make([]Node, t.CountNodes()) t.Nodes(nodes) Even though this required me to traverse the tree twice (once to count and the other to populate the list of nodes) the savings were considerable.
- tetha 8y agoYeah, optimization is hard for two reasons: - No the bottleneck is somewhere else. Even considering this rule, it's not where you thought it to be even after discarding your first two ideas. - There is no end to optimization. You can just find the problem, and then move the problem to another part of the code. It's less like capture the flag, and more like hot (or slow) potato. I guess you could be done with optimizations if you've built thoroughly optimized ASICs, because then you can blame electrons for wiggling too slow. But at that point I'd be impressed, a lot.