Significant GC performance penalty

[Rob T]

On Friday, 14 December 2012 at 20:33:33 UTC, H. S. Teoh wrote:
>
> (I actually did that once, many years ago, for a real app that 
> actually
> made a sale or two. It was a good learning experience, and 
> helped me
> improve my coding skills just from knowing how the machine 
> actually
> works under the hood, as well as learning why it's so important 
> to write
> code in a well-structured way -- you have no choice when doing
> large-scale coding in assembler, 'cos otherwise your assembly 
> code
> quickly devolves into a spaghetti paste soup that no human can 
> possibly
> comprehend. So I'd say it was a profitable, even rewarding 
> experience.
> But I wouldn't do it again today, given the choice.)
>
>
> T

Yeah, I did that too long ago and I'm happy to have learned the 
skills because it's the ultimate coding experience imaginable. If 
you don't do it very carefully, it goes all to hell just like you 
say. Best to let the machines do it these days, even if I could 
do it 10x better, it'll take me 100's of years to do what I can 
do now in a day.

Everyone, thanks for the responses. I got some great ideas 
already to try out. I think at the end of the day, my code will 
be better performing than my old C++ version simply because I 
will be considering the costs of memory allocations which was 
something I really never thought about much before. I guess 
that's the positive side effect to the negative side effect of 
using a GC. I agree like many of you have commented, having a GC 
is a pro-con trade off, positive in some ways, but not all. 
Optimize only where you need to, and let the GC deal with the 
rest.

--rt