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