toString refactor in druntime

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Fri Oct 31 04:42:05 PDT 2014


On 10/31/14 4:40 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at gmx.net>" 
wrote:
> On Thursday, 30 October 2014 at 20:15:36 UTC, Steven Schveighoffer wrote:
>> 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.
>
> OTOH, ArrayOfStrings shows that allocating is worse by several orders of
> magnitudes. This will not change on any architecture. And the simple
> sink variant is still faster than the rest by almost an order of
> magnitude, this may also be unlikely to be much different on these
> architectures.

I find it hard to believe that the delegate version is going to be 
slower than the memory version on any architecture also. But I must 
defer to Manu as the expert in those architectures. This is why I asked 
for a test. The presented data is useful, but not for the purpose of my 
query. I need to know if it performs bad on these platforms, not how it 
performs on x86. We should be willing to entertain other proposals for 
how toString should work, but not if it's proven that what we have will 
suffice.

It should be possible to perform such a test without D support.

In any case, I think there is still room for improvement inside the 
implementations of toString as has been mentioned.

-Steve


More information about the Digitalmars-d mailing list