5
votes

When I asked this question a while ago, the FastString unit came to solve my problem.

Now I am starting to migrate my software from D7 to XE2. My question is, what alternatives do I have now since it appears that FastString will no longer solve the problem?

...or, more optimistically, does Delphi itself solves this performance issues?

2
Prematurely optimizing, are we? ;) - Wait until you can actually determine that you have an issue. Then come back here with the specific problem and people will most likely be able to help.500 - Internal Server Error
Hi. Not quite. If you see my refered question you can see that I do have this issue. I´m trying to reduce the problems that I´ll probably have when migrating.Ricardo Acras
I understand that you have it now (or would have if it weren't for FastString) but my point is that the metrics on XE2 might be completely different.500 - Internal Server Error
A lot of the FastCode stuff was incorporated into the VCL in recent versions. You may not need anything external any longer. I'd suggest trying native Delphi RTL code first, and worry about finding anything else later. You may be looking for a solution to a problem that no longer exists.Ken White
Interesting thing how StackOverflow is sometimes ambiguous. I asked the original question and it got 7 upvotes and a consistent answere. I ask the same question, but to a different version of Delphi and get 2 downvotes and suddenly get too vague.Ricardo Acras

2 Answers

6
votes

A Lot of the FastCode routines have been included in recent Delphi, so you might not need 3rd party libraries anymore.
Try with the stock RTL/VCL, then see if you still have a problem and what would be the best solution to solve it in the new environment.

3
votes

Being concerned about the impact of Unicode on the famously excellent string performance in Delphi (which FastStrings elevated to an extreme level), I undertook a series of comparative benchmarking tests comparing Delphi 7, 2007, and 2009 soon after 2009 was released and these tests included some FastStrings comparisons.

The conclusions were that despite the fact that yes, the RTL has seen some significant improvements that negate the need for FastStrings, there are however (or were, at the time of Delphi 2009) some potential "gotcha's" waiting to catch you out if you simply and naively assumed that everything was sweet-as in the Delphi 2009+ garden.

And ultimately, the overhead of Unicode eats up a lot of the gains from 2009+ (which is not something that FastStrings could ever have worked around as a lot of the boosts in FastStrings relied on reliable artefacts of ANSI strings specifically that do not apply to Unicode).

It is worth noting that I haven't revisited these tests since, and it might be interesting to repeat the exercise now taking into account Delphi 2010, XE and XE2 to see if any further improvements have been made in these releases.

I may undertake this once I have finished preparing the Smoketest framework - that I used to conduct the tests initially - for release, by way of providing an example.