toString refactor in druntime

[Jonathan Marler via Digitalmars-d]

On Friday, 31 October 2014 at 11:42:05 UTC, Steven Schveighoffer 
wrote:
> 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
I wrote a Windows CE app to run on our printers here at HP to 
test what the Microsoft ARM compiler does with virtual function 
calls.  I had to do an operation with a global volatile variable 
to prevent the compiler from inlining the non-virtual function 
call but I finally got it to work.

Calling the function 100 million times yielded the following 
times:

Windows Compiler on ARM (Release)
-------------------------------------------
NonVirtual: 0.537000 seconds
Virtual   : 1.281000 seconds

Windows Compiler on x86 (Release)
-------------------------------------------
NonVirtual: 0.226000 seconds
Virtual   : 0.226000 seconds

Windows Compiler on x86 (Debug)
-------------------------------------------
NonVirtual: 2.940000 seconds
Virtual   : 3.204000 seconds


Here's the link to the code:

http://marler.info/virtualtest.c