Significant GC performance penalty

[Rob T]

On Friday, 14 December 2012 at 18:46:52 UTC, Peter Alexander 
wrote:
> Allocating memory is simply slow. The same is true in C++ where 
> you will see performance hits if you allocate memory too often. 
> The GC makes things worse, but if you really care about 
> performance then you'll avoid allocating memory so often.
>
> Try to pre-allocate as much as possible, and use the stack 
> instead of the heap where possible. Fixed size arrays and 
> structs are your friend.

In my situation, I can think of some ways to mitigate the memory 
allocation  problem, however it's a bit tricky when SELECT 
statement results have to be dynamically generated, since the 
number of rows returned and size and type of the rows are always 
different depending on the query and the data stored in the 
database. It's just not at all practical to custom fit for each 
SELECT to a pre-allocated array or list, it'll just be far too 
much manual effort.

I could consider generating a free list of pre-allocated record 
components that is re-used rather than destroyed and reallocated. 
However knowing how many records to pre-allocate is tricky and I 
could run out, or waste tons of RAM for nothing most of the time. 
End of day, I may be better off digging into the GC source code 
itself and look for solutions.

> I avoid using the GC when using D and I feel like I still have 
> a lot of freedom of expression, but maybe I'm just used to it.

I'd like to do that too and wish I had your experience with how 
you are going about it. My fear is that I'll end up allocating 
without knowing and having my apps silently eat up memory over 
time.

At the end of the day, there's just no point in having a GC if 
you don't want to use it, so the big question is if a GC can be 
made to work much better than what we have? Supposedly yes, but 
will the improvements really matter? I somehow doubt it will.

When I look at GC based apps, what they all seem to have in 
common, is that they tend to eat up vast amounts of RAM for 
nothing and perform poorly. I'm speaking mostly about Java apps, 
they are terrible with performance and memory foot print in 
general. But also C++ apps that use built in GC tend to have 
similar issues.

It may be that the GC concept works far better in theory than in 
practice, although due to the performance penalty work-a-rounds, 
you may end up writing better performing apps because of it, 
however that's NOT the intention of having a GC!

--rt