views:

386

answers:

5

I converted my program from Delphi 4 to Delphi 2009 a year ago, mainly to make the jump to Unicode, but also to gain the benefits of all those years of Delphi improvements.

My code, of course, is therefore all legacy code. It uses short strings that have now conveniently all become long Unicode strings, and I've changed all the old ANSI functions to the new equivalent.

But with Delphi 2009, they introduced the TStringBuilder class, presumably modelled after the StringBuilder class of .NET.

My program does a lot of string handling and manipulation, and can load hundreds of megabytes of large strings into memory at once to work with.

I don't know a lot about Delphi's implementation of TStringBuilder, but I heard that some of its operations are faster than using the default string operations.

My question is whether or not it is worthwhile for me to go through the effort and convert my standard strings to use the TStringBuilder class. What would I gain and lose from doing that?


Thank you for your answers and leading me to my conclusion, which is not to bother unless .NET compatibility is required.

On his blog on Delphi 2009 String Performance, Jolyon Smith states:

But it looks to me as if TStringBuilder is there primarily as a .NET compatibility fixture, rather than to provide any real benefit to developers of Win32 applications, with the possible exception of developers wishing or needing to single-source a Win32/.NET codebase where string handling performance isn’t a concern.

+5  A: 

According to Marco Cantu not for speed, but you might get cleaner code and better code compatibility with .Net. Here (and some corrections here) another speed test with TStringBuilder not being faster.

Lars Truijens
Thanks for the links. They helped. But I can't agree with you that StringBuilder gives cleaner code. I definitely like: s := s + s2; better than: SB.Append(s2);
lkessler
From the Marco Cantu article, I believe he meant when adding various data types. Still not a huge difference, of course.
stg
+7  A: 

To the best of my knowledge TStringBuilder was introduced just for some parity with .NET and Java, it seems to be more of a tick the box type feature than any major advance.

Consensus seems to be that TStringBuilder is faster in some operations but slower in others.

Your program sounds like an interesting one to do a before/after TStringBuilder comparison with but I wouldn't do it other than as an academic exercise.

LachlanG
+3  A: 

TStringBuilder is basically just a me-too feature, like LachlanG said. It's needed in .NET because CLR strings are immutable, but Delphi doesn't have that problem so it doesn't really require a string builder as a workaround.

Mason Wheeler
+2  A: 

TStringBuilder was introduced solely to provide a source code compatible mechanism for applications to perform string handling in Delphi and Delphi.NET. You sacrifice some speed in Delphi for some potentially significant benefits in Delphi.NET

The StringBuilder concept in .NET addresses performance issues with the string implementation on that platform, issues that the Delphi (native code) platform simply does not have.

If you are not writing code that needs to be compiled for both native code and Delphi.NET then there is simply no reason to use TStringBuilder.

Deltics
It's not true that it was introduced solely for source code compatibility. That was part of it, but another strong reason is that it is a powerful class to use, and because some people prefer it's ability to do the fluent coding pattern. Bottom line -- use it if you want, don't use it if you don't want.
Nick Hodges
Genuinely curious: "Powerful" how? Why? As for fluent? Yes well, as you say, use it if you want, don't use it if you don't want (or if you like to hold on to your sanity when debugging <grin>).
Deltics
@Deltics - It may be true that TStringBuilder was introduced solely for .NET compatibility, but I'd guess that that was about 95% of the reason ;-) what are the odds that TStringBuilder would have been introduced if the Delphi.NET requirement had never existed?
IanH
+1  A: 

I use it in a lot of situations similar to the TStringList.Create / Add pattern (which adds a new line to the Text of the stringlist, TStringBuilder just adds characters).

It makes my code a lot cleaner.

--jeroen

Jeroen Pluimers