More embarrassing microbenchmars for D's GC.

Steven Schveighoffer schveiguy at yahoo.com
Thu Sep 16 05:23:34 PDT 2010


On Thu, 16 Sep 2010 06:41:14 -0400, Rounin <davidjo at student.matnat.uio.no>  
wrote:

> Thank you for that advice. I'm using GDC because it's available from  
> Ubuntu
> Linux's package system, whereas DMD currently is not. (And the .deb  
> posted on
> digitalmars.com is only for i386.) Hopefully, D will gain more  
> popularity and more
> up-to-date tools will be made available.

I've heard that dmd is a bit tricky to set up on a 64-bit system (mine is  
32-bit), but it will give more credence to your position to use the latest  
available tools.

>
> By the way, today I re-compiled the program with a "std.gc.enable;"  
> right before
> the final "return 0" statement, and it still runs in 0.68 seconds. So  
> either those
> objects aren't marked as needing garbage collection, or it's really just  
> an issue
> of keeping the garbage collector from activating too quickly.

The GC runs are not scheduled.  Essentially, you are probably encountering  
a syndrome where the GC runs more than it should.  This usually occurs  
when incrementally allocating large amounts of memory without dropping any  
of it.

The GC colleciton runs when allocating memory cannot find any free  
memory.  Most likely this is what's happening:

allocate -> No free memory available -> run GC collection, get nothing  
back -> allocate more memory from OS -> allocate...

Of course, the allocations will succeed for a bit after getting OS memory,  
but the GC collection is run way too often (as your profiling suggests).

Disabling it at the beginning, then enabling it at the end means it's  
going to run at most once.  Essentially, you take out the "run GC  
collection" step, everything else is the same.  Given that 87% of the run  
time is spent in the collection cycle, it's pretty obvious why this  
reduced your runtime ;)

-Steve


More information about the Digitalmars-d mailing list