Sloc Cloc and Code – What Happened on the Way to Faster Cloc

Nice to see this hitting the front page. None of my submissions of it ever did. Happy to answer any questions about it here should they come up.<p>Certainly the biggest thing I took away from this was that the GC in Go is a far larger overhead than you would think, even for something that runs in 30ms.

I was reading this and I was wondering that perhaps it would be better define a line as &quot;80 characters of code&quot;, and measure by characters, then divide by 80 to get lines of code.<p>The whole point of measuring lines of code is to get some sense of the complexity of the code base, but if what if one code base has lots of short lines, and another code base has lots of long lines. How would this be resolved?

Could you try and reorder the state checks to occur with decreasing state-transition probability? I.e. if I am currently in code, it is most likely that I will be in code next state as well, a bit less likely that I&#x27;ll be in a single line comment, and even less likely that I&#x27;ll be in a multiline comment. If I&#x27;m in a multiline comment, I will most likely be in a multiline comment next, or code, but unlikely to be in a single line comment.<p>Amongst a few equiprobable state transitions, ordering the checks by increasing expense might also help.

One thing the linked ripgrep post doesn&#x27;t tell you is that line counting is also done with SIMD since it started using bytecount (<a href="https:&#x2F;&#x2F;github.com&#x2F;llogiq&#x2F;bytecount" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;llogiq&#x2F;bytecount</a>) some months ago, which sped up some workloads with line numbers considerably.

well the cost estimate is a little bit funny. Probably inaccurate :D<p>&gt; Estimated Schedule Effort 25.879043 months<p>&gt; Estimated People Required 18.118657<p>Well I&#x27;m working alone on the project for 4 years...