On Feb 12, 2006, at 2:17 PM, Theodore H. Smith wrote:
On 12 Feb 2006, at 19:07, Theodore H. Smith wrote:
From: Charles Yeomans <[EMAIL PROTECTED]>
Date: Sun, 12 Feb 2006 12:13:27 -0500
On Feb 12, 2006, at 2:19 AM, Ronald Vogelaar wrote:
----- Original Message ----- From: "Theodore H. Smith"
<[EMAIL PROTECTED]>
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.
I concur. A couple of months ago, I wrote a FastString replacement
in
pure RB (I called it SpeedString), that, in the end, was just as
fast
as Theo's FastString.
Still, I ended up continuing to use FastString for exactly the
reasons
Theo mentions.
I too am suspicious of the statement about Join, but perhaps I'm
overlooking something. Charles, could you share a simple code
example?
Sure. At <http://www.declaresub.com/ElfDataJoinProject.zip> is a
project file that requires Rb2006 (and Theo's plugin), and the
compiled
MacOS application. On my machine, an aging 12" 867 mhz Powerbook,
Join concatenates the elements of a 100000 element string array in
5-6
ticks; performing the same operation using a FastString object takes
9-10 ticks.
Unfortunately, I don't have RB 2006 to verify this.
I've uploaded the source code to
http://www.elfdata.com/plugin/showcase/showcase2006.rb.zip
I should have said this: It's important you use the showcase2006
project I put up here, not Charles's, because this one makes a fair
comparison.
I took a look at Charles's example, there are a few things that don't
make it a fair comparison.
1) No pragmas. All plugin functions are unfairly penalised by RB if
you don't have pragmas. And all loops have background stuff going on
(whereas join won't). So this is a double penalty.
#pragma disableBackgroundTasks is in my source code. The other
settings don't appear to matter.
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.
--------------
Charles Yeomans
_______________________________________________
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>
