Significant GC performance penalty

[Peter Alexander]

On Friday, 14 December 2012 at 19:24:39 UTC, Rob T wrote:
> 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.

Maybe I have misunderstood, but it sounds to me like you could
get away with a single allocation there. Just reducing the number
of allocations will improve things a lot.

>> 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.

This shouldn't be a problem. I occasionally recompile druntime
with a printf inside the allocation function just to make sure,
but normally I can tell if memory allocations are going on
because of the sudden GC pauses.

> 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.

D's GC has a lot of headroom for improvement. A generational GC
will likely improve things a lot.

> 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.

The problem with Java is not just because of the GC. Java eats up
huge amounts of memory because it has no value-types, so
*everything* has to be allocated on the heap, and every object
has 16 bytes of overhead (on 64-bit systems) in addition to
memory manager overhead.

This is a great presentation on the subject of Java memory
efficiency:
http://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf

> 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!

When it comes to performance, there is always a compromise with
usability. Even malloc performs poorly compared to more manual
memory management. Even automatic register allocation by the
compiler can lead to poor performance.

The only question is where you want to draw the line between
usability and performance.