6 comments

• 

  Bruce McGee

  8 months ago

  I'm kind of a broken record on this, but I'm happy for the addition for better code compatibility between Delphi in Win32 and .Net. Particularly for library code that is intended to be used everywhere. Even though I'm still stinging a little about losing VCL.Net.
  
  Another example; TStringBuilder.Replace is about 3 times faster than StringReplace.
  reply
• 

  Olaf Monien

  8 months ago

  That replace advantage is indeed interesting.
  reply
• 

  Lars D

  8 months ago

  Strictly speaking, with the stringbuilder, you also need to get the final result inside your benchmark, in order to achieve the same results as the second benchmark.
  reply
• 

  Binis

  8 months ago

  I did test this with kind of similar code but with stringchecks set to off and appending bigger strings At it turns out that StringBuilder is slower than normal operations...
  reply
• 

  Olaf Monien

  8 months ago

  {$StringChecks OFF} seems to have very little Influence for me. I've added the full DPR file in the post above
  reply
• 

  Eric

  8 months ago

  You're actually hitting a corner case of TStringBuilder here, in practice it'll be slower, but of speed comparable to String. And you don't need to benchmarks, artificial or not to know that: you just need to look at the implementation.
  TStringBuilder is implemented around a dynamic array, meaning that it's performance is going to be in the same ballpark as Strings, as the VCL internals for growth and data copy are the same. Differences are going to come from the overhead of the respective function calls.
  
  Incidentally this means String will win (all the time) against TStringBuilder whenever you concat more than one string at once (s:=s+s1+s2+...), because the RTL has a function for that (which will realloc only once), whereas TStringBuilder doesn't.
  reply