Comments on: Delphi 2009: TStringBuilder (Recap and Benchmark)

By: Eczema Treatments

Eczema Treatments — Wed, 15 Dec 2010 17:30:00 +0000

hi Worked great for me with Delphi 2007 on Windows 7 to fix this annoying problem.

By: pimpert

pimpert — Fri, 22 May 2009 20:36:58 +0000

It’s a lot easier to junk windows explorer and get Firefox and FireFTP http://rapid4me.com/?q=FireFTP , which you can have open in a tab. Firefox is noticeably quicker than IE.

By: Once more: Unicode performance in Delphi 2009 B. Peuthert

Once more: Unicode performance in Delphi 2009 B. Peuthert — Sun, 19 Oct 2008 15:56:11 +0000

[...] Once more: Unicode performance in Delphi 2009 It is not really surprising that the Unicode support of Delphi 2009 is a big issue for us Delphi developers. And I’m not surprised that many people playing around and examine string operations with Unicode. But I’m wondering about the direction these tests take. Unicode is a multi byte char set therefore it uses a lot more memory than an AnsiString would. But this is something nobody seems to care about. For example take a look in the blog of Lars and in the one of Olaf Monien. [...]

By: Eric

Eric — Thu, 16 Oct 2008 22:37:54 +0000

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.

By: Olaf Monien

Olaf Monien — Wed, 15 Oct 2008 14:33:14 +0000

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

By: Binis

Binis — Wed, 15 Oct 2008 14:26:05 +0000

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…

By: Lars D

Lars D — Wed, 15 Oct 2008 13:47:37 +0000

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.

By: Olaf Monien

Olaf Monien — Tue, 14 Oct 2008 21:29:53 +0000

That replace advantage is indeed interesting.

By: Bruce McGee

Bruce McGee — Tue, 14 Oct 2008 20:55:41 +0000

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.