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/

Comments

  1. Try doing a SetLength to required end size before trivial concats as well.

    ReplyDelete
  2. Lars 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 :)

    ReplyDelete
  3. Nice comparison. When I roll Format for concats I usually do it all there, ie result := Format ('%s %d', [result, i]);

    Just habbit, never benchmarked it nor been in a situation where it was critical. Though think I will just for kicks :-)

    ReplyDelete
  4. 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

    ReplyDelete
  5. Asbjø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 ;-)

    ReplyDelete
  6. Eric 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).

    Still, 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.

    ReplyDelete
  7. Hooray for Delphi Strings! Very insightfull post. Thanks for that!

    ReplyDelete

Post a Comment