std.container.RedBlackTree versus C++ std::set

Rob T alanb at ucora.com
Wed Feb 13 23:28:00 PST 2013


On Thursday, 14 February 2013 at 00:25:15 UTC, FG wrote:
> On 2013-02-14 01:09, Rob T wrote:
>> You can check if disabling the GC just before the insert 
>> process improves the
>> performance. You may see 3x performance improvement. Disabling 
>> is safe provided
>> you re-enable, this can be done reliably with scope(exit) or 
>> something similar.
>
> How did you know? It was 3x in my case. :)
> Well, even more but the program had to wait 2 seconds at the 
> end to collect.
> With LIMIT at 10M, g++: 5.0s, gdc: 27.0s and 8.7s with 
> GC.disable.
> Internal memory handling by containers - yeah, can't wait to 
> see that happen!

Oh yes, I forgot to mention you can expect ~2 second additional 
delay from re-enabling the CG.

How did I know? Read this ...
http://forum.dlang.org/thread/waarzqtfcxuzhzdelhtt@forum.dlang.org

So it seems that we can get close to g++ performance with some 
manual tweaking of the GC, which is good, but you have to know 
this and know where to make the adjustments.

What we really need is a better GC with manual fine tuning 
control over how it operates, with an ability to gain feed back 
from it to understand where and when it may be doing something 
stupid, and even better than that is if we could use D completely 
without the GC, which may be a requirement for certain types of 
applications. Unfortunately, a certain subset of D depends on 
there being a method of automated garbage collection in place, so 
currently you cannot use all of D without a GC.

--rt


More information about the Digitalmars-d-learn mailing list