Re: definition list recommendations?
Re: definition list recommendations?
- Subject: Re: definition list recommendations?
- From: has <email@hidden>
- Date: Thu, 27 Jan 2005 22:33:34 +0000
Emmanuel wrote:
Has wrote [...] that his libraries [...] are very fast, unlike XMLLib.
Oooh, time for a teensy correction: I wrote that they were broadly
comparable speed-wise (i.e. both extremely slow compared to what a
native dictionary type would be), and that each suffers one major
performance problem (in different areas).
XMLLib stores the data that you submit to it into a persistent structure
Serializing and de-serializing program data is, of course, XMLLib's
greatest strength. While it can also be used to provide an erstaz
dictionary in the absence of a built-in type, this isn't something
it's nearly as well suited to.
Has' libraries are O(log n) for retrieving
For folks not familiar with calculating program efficiency, big-O
notation, etc., O(log n) means as close to constant time as makes no
significant difference.
and not very fast at storing.
Storing items in Types's Dictionary objects has O(n) efficiency, i.e.
speed varies directly in relation to the number of items already
stored. With Type's Dictionary object, performance is just peachy
when there's only a few hundred items or less, tolerable up to a
couple thousand, and becoming increasingly painful beyond that. That
means it doesn't scale well but should suffice in light-to-moderate
use [1].
XMLLib has a different performance problem when storing. While the
number of items already stored has no appreciable difference on the
time it takes to add another, as with any osax, every value sent to
it has to be packed into an Apple event first, a decidedly less than
constant-time operation. And when those values are large or complex
objects like lists, records, script objects and really large strings
its performance really plummets: packing a string is O(n), packing
lists and records is much worse (due to an inefficient list-packing
algorithm in the Apple Event Manager), and I don't even like to think
about packing script objects. :p
So as Emmanuel says, we're both right [2].
To which I'd add that we're really just a couple of little Dutch boys
with their fingers stuck into a crumbling old dyke. A well-optimised
native dictionary type would be a hundred times faster than either of
our solutions and suffer none of their disadvantages either. I'm sure
y'll all know where to go to file feature requests by now.... ;)
HTH
has
[1] Actually, this can be said of AppleScript in general. If you're
going to be doing heavy-duty data processing, other languages like
Perl and Python scale much, much better. This is why I'm not so
bothered by Types's limitations - I just go use one of those when the
workload is too much for AppleScript.
[2] When he's not misquoting me, anyway. ;p
--
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