#pragma disableBackgroundTasks is in my source code. The other
settings don't appear to matter.
Yes, I missed that. The necessary pragma is there.
2) He is getting his strings from a premade array. This is not a fair
test. In real life, we'd have to create the array during the process,
not before!
3) The array is not redimed to -1, before the time test is done. This
also is not a real life situation. Temporaries disposal time
*must* be
included. What if we wanted to do a whole batch of those
operations in
real life? Would we leave all the unneeded temporary arrays around
without disposing them? Or would we first redim the array to
ubound of
-1. If we didn't we'd run out of RAM very quickly.
That said, it might still turn out that RB's join is faster. I'd
consider it unlikely, but let's see!
In real life, I use the String concatenation operator 99.5% of the
time. There is no such thing as a fair test. Here, the test is the
following -- given a String array, return the concatenation of the
array elements as a String. For this test, Join performs a lot faster
than your FastString class. If you don't like the results, you can
look for a test at which your code wins.
That's rather disingenuous.
There is such a thing as a real life test. Just because you use RB's
+ operator, does not mean the rest of the world does.
Those of us who do high performance software, do not. I cannot
imagine anyone using an array of strings for a high performance
situation, it is a totally arbitrary situation.
The best example of a real life situation, is XML. In XML, you have
many small bits and pieces which need appending. You DO NOT have
these bits and pieces as a 1D array.
In real life, you have data sources coming in from all over the
place. Saying that a 1D array represents real life just makes no sense.
I've done many other high performance string creation programs, and
none of them had a data source which is a 1D array.
I would say that in 99.9% of the cases we are going to come across, a
buffered approach is better suited to solving string appending, than
a string array approach. The string array still suffers from having
it's own buffer, after all.
The fact that you can say "look for a test", implies that my
FastString (and buffered approaches in general) is better suited for
a very few number of problems.
Honestly, I don't believe that you have sufficient experience in
creating long file formats to be speaking on the subject of creating
long strings with the authority of experience.
I do. My second application I made was my XML Editor.
--
http://elfdata.com/plugin/
_______________________________________________
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>
