C++ vs. D memory management performance (Was: Faster Virtual Method Dispatch)

Sean Kelly sean at f4.ca
Thu Apr 27 13:36:43 PDT 2006


I ran some quick tests this morning using the word count example code 
and here are my results so far:


D version (wc):

Execution time: 0.179 s
Execution time: 0.183 s
Execution time: 0.149 s

C++ version 1 (wccpp2):

Execution time: 0.216 s
Execution time: 0.263 s
Execution time: 0.183 s

C++ version 2 (wccpp3):

Execution time: 0.221 s
Execution time: 0.168 s
Execution time: 0.185 s

C++ version 3 (wccpp4):

Execution time: 0.191 s
Execution time: 0.243 s
Execution time: 0.142 s


The apps were compiled according to the word count description and timed 
using ptime (I had some applications open during the tests so the 
results may be a tad inaccurate).  wccpp2 is straight from the web page, 
wccpp3 replaces the C++ IO code with a C version quite similar to the D 
code in std.file, and wccpp4 replaces std::string with slice<char>.

You'll notice that there is practically no difference between the 
std::string and slice tests (wccpp3 and wccpp4), and I think this is to 
be expected.  Typical C++ string implementations have a "small string 
optimization" to avoid dynamic allocations for strings of less than 16 
characters.  And since there are likely very few words in the sample 
text that are larger than this, there are few if any dynamic allocations 
being performed by std::string.  Thus I think the real notable 
performance difference between C++ and D is that C++ uses a balanced 
binary tree while D uses a hash table.

I tried replacing std::map with a hash table implementation (technically 
an unordered_map implemented according to C++ TR1 that I did for a 
project a while back), but DMC choked on it and I don't have any more 
time to spend on this right now.  When I get a chance, I'll try to 
verify that the unordered_map code conforms to the C++ spec (it compiles 
cleanly at WL:4 in Visual Studio 2005) and will file a bug report for 
DMC if it does.  For reference, the bulk of the errors I saw were 
related to symbol lookup--a template class using static and non-static 
data from a parent class without fully qualifying the names--adding some 
'using' statements took care of these.  The final one was a bit more 
subtle and offered me almost no useful information to go on, so that one 
may take some investigation.


Sean



More information about the Digitalmars-d mailing list