Re: minimum function? (Modified by Simon Forster)
Re: minimum function? (Modified by Simon Forster)
- Subject: Re: minimum function? (Modified by Simon Forster)
- From: has <email@hidden>
- Date: Thu, 7 Apr 2005 10:27:28 +0100
Axel Luttgens wrote:
> >>Speed! Just a matter of speed...
> >
> >Efficiency, to be precise. Not quite the same thing.
>
>With regards to Simon's original question, "efficiency" is a rather
>daring terminology.
Not really. But it is a 'real CS' concept, so is a bit of a step up for your average non-programmer (which is what many AS users are). It's pretty much impossible to discuss performance and optimisation issues in any meaningful way without a minimum understanding of what 'speed' and 'efficiency' actually mean and how they're measured.
>For now on, one may only notice additional and rather illogical coding
>introduced in order to obtain higher execution speeds;
Only by folk who don't know what they're doing. First rule of performance optimisation: don't even attempt to do it unless you actually know how. You're just wasting your time and fouling up your code otherwise.
>the rationality
>acompanying the concept of efficiency is quite elusive in this very
>precise case.
It is simply wrong to say naive min() implementation is 'slow'. It's extremely fast in certain conditions, and outrageously slow in others. To understand this apparent discrepancy you have to measure its efficiency, and to do that in any meaningful way you need to know what 'efficiency' is and how it differs to 'speed'. There's no getting around this.
The only alternative is to skip the understanding phase and just go with the stock workaround for dealing with performance problems on large lists, although doing things when you don't understand the what, why or how is not without problems of its own. [1]
Yes, the situation sucks, and AppleScript should be firmly spanked for introducing newcomers to such levels of suckitude far sooner than is actually necessary. But hey, you pays your money... :/
> >>Now, unless I'm wrong, a true explanation for this has never been provided.
>
> > Short version, IIRC:
>
>Isn't it exactly what I said?
>We don't have a true explanation.
>Just a quasi-information: it seems that some internal checks are not
>performed under certain circumstances.
Which is all the information you need, and way more than you ought to know [2]. All you need to know is that there's a problem, this is what causes it, this is how it manifests itself, and this is how to deal with it. The exact machine-level operations involved really aren't important and won't tell you anything more of use, unless you're an Apple engineer attempting to fix it (hey, hope springs eternal...:p).
HTH
has
[1] It would probably help if some kind soul were to write up a nice troubleshooting checklist ("... 4. Is your script unexpectedly slow? 4a. Does it deal with large lists? 4b. Does it send lots of commands to applications? 4c. Does it use a loop to build up large strings? ..."), allowing users to identify common problems by answering yes/no questions that lead them to a stock solution, and post it in a prominent location like macscripter.net so that folk will know to find it.
[2] That AS users should need to know _anything_ about the internal mechanics of AppleScript in the first place is an indication that the language is failing to do its job properly. The whole point of very high level languages like AS is to hide all such nastiness from the user so they never know anything about it.
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden