Sloc Cloc and Code – What Happened on the Way to Faster Cloc
1–10 of 23 posts
Re: Sloc Cloc and Code – What Happened on the Way to Faster Cloc
#2Nice 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.
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.
Re: Sloc Cloc and Code – What Happened on the Way to Faster Cloc
#3Nice 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. 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 a C++ developer now working on a Go project. I'm always suspicious of garbage collection, but people say it is an exaggerated claim. Glad to hear someone confirm this.
Re: Sloc Cloc and Code – What Happened on the Way to Faster Cloc
#4Nice 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. 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 a C++ developer now working on a Go project. I'm always suspicious of garbage collection, but people say it is an exaggerated claim. Glad to hear someone confirm this.
Depending on what you are working on you can pre-allocate everything you need and then turn the GC off. You can even do it in code which is nice. Similar approach to Java.
Re: Sloc Cloc and Code – What Happened on the Way to Faster Cloc
#5Nice 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. 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 a C++ developer now working on a Go project. I'm always suspicious of garbage collection, but people say it is an exaggerated claim. Glad to hear someone confirm this.
This is a case of "speed" meaning more than one thing. Go optimizes for latency, not throughput, so even though each collection pause is very short, you end up with a lot of them.
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).
Re: Sloc Cloc and Code – What Happened on the Way to Faster Cloc
#6I was reading this and I was wondering that perhaps it would be better define a line as "80 characters of code", and measure by characters, then divide by 80 to get lines of code.
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?
Re: Sloc Cloc and Code – What Happened on the Way to Faster Cloc
#7I was reading this and I was wondering that perhaps it would be better define a line as "80 characters of code", and measure by characters, then divide by 80 to get lines of code. 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?
Count bytes via wc?
Re: Sloc Cloc and Code – What Happened on the Way to Faster Cloc
#8I was reading this and I was wondering that perhaps it would be better define a line as "80 characters of code", and measure by characters, then divide by 80 to get lines of code. 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?
Number of characters is a meaningless metric because it depends on identifier lengths, which can be very different between coding styles. A much fairer metric would therefor be the number of lexer tokens in my opinion.
Re: Sloc Cloc and Code – What Happened on the Way to Faster Cloc
#9Nice 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. 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 a C++ developer now working on a Go project. I'm always suspicious of garbage collection, but people say it is an exaggerated claim. Glad to hear someone confirm this.
The problem with garbage collection in most cases isn't really performance but correctness.
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.
Re: Sloc Cloc and Code – What Happened on the Way to Faster Cloc
#10I was reading this and I was wondering that perhaps it would be better define a line as "80 characters of code", and measure by characters, then divide by 80 to get lines of code. 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?
There would be a bias toward very long identifiers?