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