Re: Problems with speed & issues with coercion in OS 9.2.2
Re: Problems with speed & issues with coercion in OS 9.2.2
- Subject: Re: Problems with speed & issues with coercion in OS 9.2.2
- From: Kai Edwards <email@hidden>
- Date: Tue, 29 Jan 2002 01:43:49 +0100
>
Date: Sun, 27 Jan 2002 21:34:51 +1100
>
Subject: Re: Problems with speed & issues with coercion in OS 9.2.2
>
From: Shane Stanley <email@hidden>
>
To: AS lists <email@hidden>
>
>
On 27/1/02 7:23 PM +1000, Kai Edwards, email@hidden, wrote:
>
>
> The results were then translated into an index: slowest method = 100. This
>
> is how they panned out - listed from slowest to fastest:
>
>
>
> last text item (multi tid reset): 100
>
> last text item (single tid reset): 94
>
> last chararacter: 67
>
> original script: 55
>
> folder of info for: 49
>
>
Keep in mind that "folder of info for" is highly dependent on how many files
>
are in the folder and its subfolders; big folders can take a long time.
Wow! - You're not kidding, are you Shane?
I tried a similar test to compare an empty folder with one containing about
500MB worth of files. (I didn't take the trouble to count the files and
subfolders, but most files were relatively small - and therefore quite
numerous - while the nesting of subfolders was an average of about 4-5
levels.)
The calculation for the larger folder took about 170 times longer than the
time taken to query the empty one (long enough for me to think I'd crashed
my machine)!
Since the folder used in the original tests was also an empty one, the
initial results were highly misleading. My 500MB folder would have returned
an index of well over 8,000 - way off the scale compared to other methods.
Further investigation revealed that the time taken to query files (as
opposed to folders) was not significantly affected. In addition, it seems
that it was not the 'folder of' property that took the extra time - but the
'info for' function.
I assume this is because another of the properties of 'info for' is 'size'
which, in the case of a folder, apparently needs to be calculated each time
- even though (in this case) we're not interested in that particular
information.
Whatever the reason, since the original script also used the 'info for'
function, its performance on a larger folder would obviously be affected to
a similar magnitude.
Many thanks for highlighting that potential pitfall!
Kai
PS:
Incidentally, I note that Nigel augmented the string-based solutions by
offering the alternative syntax 'ends with', which I had not come across
before - and which is significantly faster:
Using the same test method as before, I found that using 'ends with'
resulted in an index of 56 - the speediest of all results (considering the
anomalous variations that 'folder of' can introduce).
At first glance, this result may appear to diminish Nigel's estimate on the
speed improvements of 'ends with' over 'item -1 =', namely:
>
'Ends with' is about twice as fast as 'item -1 =' in a straight race...
However, establishing the last character of a string represented only a very
small proportion of the string-based timings. In fact, the process of
coercing a path to a string represented about 97% of the total time in each
test. So, once the path-to-string coercion had been carried out, the speed
improvement offered by 'ends with' over 'item -1 =' was indeed a substantial
one.
As Mr Spock put it so succinctly - "Fascinating..." B-)
Kai
--
**********************************
Kai Edwards Creative Resources
1 Compton Avenue Brighton UK
Telephone +44 (0)1273 326810
**********************************