Re: toString refactor in druntime

[Jonathan Marler via Digitalmars-d]

On Thursday, 30 October 2014 at 20:15:36 UTC, Steven 
Schveighoffer wrote:
On 10/30/14 2:53 PM, Jonathan Marler wrote:

Before we start ripping apart our existing APIs, can we show 
that the
performance is really going to be so bad? I know virtual 
calls have a
bad reputation, but I hate to make these choices absent real 
data.

For instance, D's underlying i/o system uses FILE *, which is 
about as
virtual as you can get. So are you avoiding a virtual call to 
use a
buffer to then pass to a virtual call later?

I think its debatable how useful this information would be but 
I've
written a small D Program to try to explore the different 
performance
statistics for various methods.  I've uploaded the code to my 
server,
feel free to download/modify/use.

Here's the various methods I've tested.
/**
   Method 1: ReturnString
             string toString();
   Method 2: SinkDelegate
             void toString(void delegate(const(char)[]) sink);
   Method 3: SinkDelegateWithStaticHelperBuffer
             struct SinkStatic { char[64] buffer; void
delegate(const(char)[]) sink; }
         void toString(ref SinkStatic sink);
   Method 4: SinkDelegateWithDynamicHelperBuffer
             struct SinkDynamic { char[] buffer; void
delegate(const(char)[]) sink; }
         void toString(ref SinkDynamic sink);
         void toString(SinkDynamic sink);

 */

Dmd/No Optimization (dmd dtostring.d):

RuntimeString run 1 (loopcount 10000000)
  Method 1     : 76 ms
  Method 2     : 153 ms

I think the above result is deceptive, and the test isn't very 
useful. The RuntimeString toString isn't a very interesting 
data point -- it's simply a single string. Not many cases are 
like that. Most types have multiple members, and it's the need 
to *construct* a string from that data which is usually the 
issue.

But I would caution, the whole point of my query was about data 
on the platforms of which Manu speaks. That is, platforms that 
have issues dealing with virtual calls. x86 doesn't seem to be 
one of them.

-Steve
Like I said "I think its debatable how useful this information 
would be".  Yes you are correct the RuntimeString isn't very 
interesting, it's just establishes a base to compare what happens 
in the "simplest" possible case.  In the real world this would 
almost never happen.  I provided the code to encourage others to 
modify it and maybe post some more interesting cases then what I 
already provided.  I wanted to get some "real world" examples of 
how each API would change the code.  I would love to see someone 
improve on my implementation on ArrayOfStrings.  I wrote this 
code in a couple hours so I'm sure there alot of room for 
improvement.