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.