问题
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?
回答1:
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.
回答2:
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.
来源：https://stackoverflow.com/questions/9072517/faststring-alternatives-to-delphi-xe2