I've tested my FastString against a class by Charles Yeomans. I got
this result:
Your graphs suggest that my code has running time O(n^2) compared to
O(n) for yours. That doesn't seem right to me, especially in light of
my own testing that suggests that your function is about twice as fast
as mine, though I can cut that difference some by removing support for
encodings as in your plugin, and certain other tricks. But it appears
that RS has made this squabble moot, as Join now looks to be 50-100%
faster than your FastString.AppendString.
The test is easy to perform, using my ElfData Showcase app, freely
available on my website. If you have an improved StringBuffer class I
can test it myself.
As for join... I should have tested it, but I didn't consider it
likely to be fast enough. I doubt that it is faster.
I assume you are talking about RB 2006? I can't see how appending to
the array and afterwards, joining, and then resizing the array to -1,
is faster than my FastString's .AppendString function and the
final .GetResult function.
Using an array has so much overhead, that is why.
Its quite possible that the relative speed advantage varies with
different input parameters. For example, length of string to append
and the number of strings to append.
Besides, while the raw speed of appending a string maybe the simplest
thing to understand and compare, my FastString class has more
advantages than simply being used as a buffer. It has a long history
of use, and from that history it has gained many tweaks and features
making it very handy and simple to use.
Just little things like .AppendIntegerAsText, or .AppendHex or being
able to set .Length, or even the operator_convert to a string. I
generally would not want to create a file format without my
FastString class.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
