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.
Steel Bank Common Lisp would be one open-source tool that has a GC optimized for throughput at the expense of latency. Full GC pauses (which are rare, but do happen) are large fractions of a second even with moderately sized heaps. However the throughput is great to the point where many workloads are just as fast with heap allocation as stack allocation, and the gc overhead is actually less than malloc/free (or new/delete).
Obviously the SBCL garbage collector is totally unsuitable for video games (there are games designed to be build with SBCL, but the allocation is done during non-interactive parts of the game).
The only thing the garbage collector does is allowing you to not think about memory. And you can not write good code if you do not know how your memory is being used.
It is a massive disservice with barely any tangible benefits.
edit: ryzen 1700, 3.8gz, 8cores 16 threads, fedora 4.16.13-300.fc28.x86_64
Tokei is definitely more accurate though, by probably a pretty wide margin. I'm hoping to get around to handling nested comments correctly soon and maybe strings.
I'll definitely have to take a look at this in detail when it's not 6am. Or on a day where I wake up at 6am instead of stay up until 6am.
The nested comments and strings will probably slow you down a lot. I know it did for me. I’m looking forward to the new GC settings in Go so I can tweak it for faster performance.
Did you ever work out why loc was performing so badly on multi core systems? Sounds like you did but curious what the bottleneck was. I don’t understand rust well enough to be able to guess sorry.
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?
Amongst a few equiprobable state transitions, ordering the checks by increasing expense might also help.
> Estimated Schedule Effort 25.879043 months
> Estimated People Required 18.118657
Well I'm working alone on the project for 4 years...
