What if you now have to concatenate many strings?
What if you now have to concatenate many strings?
Comparing a few approaches...
http://www.delphitools.info/2013/10/30/efficient-string-building-in-delphi/
Comparing a few approaches...
http://www.delphitools.info/2013/10/30/efficient-string-building-in-delphi/
Try doing a SetLength to required end size before trivial concats as well.
ReplyDeleteLars Fosdal Tried it, but the speedup for many iterations was below 10%, and there was a small penalty for the cases with fewer iterations. I guess the test case is not one in which it makes miracle, but it' a good trick anyway as it doesn't involve changing the code, so it's like a free meal :)
ReplyDeleteNice comparison. When I roll Format for concats I usually do it all there, ie result := Format ('%s %d', [result, i]);
ReplyDeleteJust habbit, never benchmarked it nor been in a situation where it was critical. Though think I will just for kicks :-)
Its interesting, I'd be interested in the multi threaded results too - in the past I have used a terribly old but very useful old style object for ANSI string building, I do wonder if it would be worth resurrecting into xe5, although I'm not sure it would work, it used to resize the string data pointer with a quick alloc (if memory serves) which I don't know is allowed these days
ReplyDeleteAsbjørn Heid It behaves much slower the longer the string gets, as Format creates a new string each time (and so copies everything each time), so your form is effectively using Schlemiel the Painter algorithm ;-)
ReplyDeleteEric Grange Suspected as much. Like I said, string ops I do haven't been anywhere near performance sensitive yet so convenience first (simple concats I use + for of course).
ReplyDeleteStill, nice to know just how bad it is :)
This post was a bit timely for me. I just benchmarked why one of our forms was so slow starting up yesterday (using your excellent Sampling Profiler). It was loading a big table into a devexpress grid for combobox lookup use. Of the time spent in Delphi code (ie not waiting for the DB), 60% was in System.Move, seemingly due to strings being duplicated left right and center. The runner up call had a local cpu use of <10%, so the rest was spread out all over.
Hooray for Delphi Strings! Very insightfull post. Thanks for that!
ReplyDelete