toString refactor in druntime

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Thu Oct 30 13:15:35 PDT 2014


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


More information about the Digitalmars-d mailing list