
Sloc Cloc and Code Revisited – Optimizing an Already Fast Go Application - ngaut
https://boyter.org/posts/sloc-cloc-code-performance/
======
nemetroid
I think the stuff about nested loops performing poorly is a misunderstanding.
There's nothing inherently bad about nested loops. The motivation given in the
previous post[0] is:

> The big breakthrough I had was after looking at the hot function I realised
> that storing the game events in a List of Arrays meant that we had a loop in
> a loop. It was however possible to flatten this into a single array of
> integers and reset the game every 11 turns with a simple if check.

The issue here wasn't nested loops, it was data structure overhead and poor
data locality from having a lot of tiny lists (11 items each, as I understand
it).

0: [https://boyter.org/2017/03/golang-solution-faster-
equivalent...](https://boyter.org/2017/03/golang-solution-faster-equivalent-
java-solution/)

~~~
saagarjha
The author recognizes this for certain cases:

> Turns out that at this small level of nested looping there is no performance
> to be gained here.

------
dullgiulio
Unsurprisingly, the biggest performance gains came from algorithmical changes,
not micro optimisations (like if instead of switch.)

The lesson is always the same: leave micro optimisations for later and spend
more time learning about data structures that can improve your code locality.

~~~
boyter
Correct. However I did find that just working on the codebase getting small
wins was enough to put my mind into thinking about it and hence able to make
that leap to the larger gains.

For the super tight loops scc uses the micro optimisations still add up though
so it wasn’t wasted effort and in the end it all came together nicely.

~~~
dbaggerman
The caveat working that way is that you can end up working towards a local
optimum, and lose sight of the forest for the trees when it comes to making
the bigger algorithmic changes.

~~~
boyter
Nobody is perfect :) I still think just getting into the mindset of a problem
is a good way to even begin to think about these larger changes though.

------
contravariant
Is there some Go specific overhead on loops? If not, why does the author seems
so obsessed with removing loops within loops?

~~~
jerf
No, Go has about the fastest loops you could want, implemented in the obvious
way at the asm level. (That is, not that Go's loops are any more extra magical
fast than any other compiled language, but they are not slow as in some
dynamic languages.) The focus is there because that's where you get wins, in
any language.

~~~
vanderZwan
Depending on the type of loop there might be runtime boundary checks, but they
can be avoided in many cases IIRC.

------
drej
I only skimmed this, but why isn’t ripgrep mentioned? (While other Rust-based
tools are.)

By the way, ripgrep author has a good writeup on performance comprison.
[https://blog.burntsushi.net/ripgrep/](https://blog.burntsushi.net/ripgrep/)

~~~
steveklabnik
Ripgrep is a similar but different kind of tool.

~~~
drej
Of course, silly me, I take loc and ripgrep to be so essential I conflated
them. Too much Christmas merriment, not enough proper thinking. Sorry.

~~~
steveklabnik
It’s all good! Have a great Christmas :)

