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.
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!
_______________________________________________
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>
