toString refactor in druntime

[Manu via Digitalmars-d]

On 31 October 2014 06:15, Steven Schveighoffer via Digitalmars-d
<digitalmars-d at puremagic.com> 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

I want to get back to this (and other topics), but I'm still about 30
posts behind, and I have to go...
I really can't keep up with this forum these days :/

I'll be back on this topic soon...