Re: possible bug? Radically different time profile for list access in script objects or by explicit reference.
Re: possible bug? Radically different time profile for list access in script objects or by explicit reference.
- Subject: Re: possible bug? Radically different time profile for list access in script objects or by explicit reference.
- From: has <email@hidden>
- Date: Tue, 12 Mar 2002 01:52:30 +0000
Michael Sullivan wrote:
>
> Anyway; Chris, while I appreciate what you're saying about deep changes not
>
> being simple to make or something to be rushed into, perhaps I could quote
>
> something Paul Skinner wrote to the macscrpt list:
>
>
> Which suggests a few things to me:
>
>
First he already saw that, because I quoted it
[oops, my bad for missing that]
>
On short lists, it's actually not a huge problem.
Well, that's the nature of the n^2 beast. However, what's considered
realistic? A 50000-item list might not be something you run into every day,
but a 5000-item one is not unreasonable and the n^2 behaviour will still
bite pretty hard. e.g. I'm going through some of my old code at the moment.
I've a recomposeList() handler that used to bite for speed:
10x10 array = {newTime:0.029, oldTime:0.045}
100x100 array = {newTime:2.446, oldTime:229.534} (4 minutes; ouch!)
And a 100x100 array doesn't sound too unreasonable either.
>
> 1. the checking you describe is inconsistently enforced to begin with.
>
> [Perhaps AS itself concurs with your own feeling that it's unnecessary?]
>
>
Not necessarily. If it's not the kind of simple overlooked temporary
>
that I proposed, the situation could be much more complicated than
>
simply that using references disables the checking. Maybe using
>
references, or objects makes it impossible to have the kind of
>
circularity checked against, or makes it much easier (take less time) to
>
check.
Hmmm. It certainly doesn't look like n^2 behaviour when references are
used, so _something_ different must be happening (taking more/less time
isn't an issue; it's how that time taken scales WRT list length that's
important).
>
The real question is: How often does this check find something
>
important and what is the benefit when it does?
One thing I've noticed is that it's much easier to cause bad behaviours and
crashes when using a my/its keyword approach. I've popped the script where
I first noticed this problem on my L33t website (scroll down to
"fastListLib") for those who care for a poke (the problem line, and its
solution, are commented).
>
In any case, without having the the actual code (which presumably is not
>
open source) available to look at, it's almost impossible to say whether
>
such a change is trivial, so we don't have much choice but to accept the
>
word of the person who *has* seen it that it probably isn't.
I'm quite sure it isn't trivial: even if the change to the source code is
easy, testing it to ensure it doesn't result in any nasty unexpected side
effects certainly won't be. Like O(n) versus O(n^2), it's that last bit
that really bites. (And I bet Chris N must sometimes think he's got a TO DO
list that exhibits at least O(n^2) behaviour, if not worse.:)
>
Bear in mind that the fact that these hacks exist lessens the need to
>
fix the problem.
They also raise some questions:
- What pitfalls do these techniques open up for the unwary to fall into?
How do you safely avoid them?
- How do you explain these techniques to folks outside of the fairly small
circle that's currently discussing and understanding them? (Rocket science
is fine for rocket engineers, but most ASer's aren't.)
- Who'll volunteer to write the definitive reference document on the subject?
- Why should we be satisfied by anything less than O(1/n) behaviour anyway? ;)
>
If you really care about speed and are working with
>
long lists, there are documented ways to do that. I didn't even realize
>
this was in the language guide until Arthur mentioned it, but there it
>
is.
Ditto. (The ASLG is a good place to go to find out more about things you
already know, but pretty hopeless for learning new stuff from scratch. It's
not something you'd flick through for 10 or 15 minutes every night for a
bit of light bedtime reading.:)
I'm going to use it now, of course; I just hope I don't have too many
sleepless nights wondering if I'm silently wreaking havoc upon unwary users
as a result. :p
Cheers,
has
http://www.barple.connectfree.co.uk/
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.