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
