Even more interesting, addressing the keys of the array by string name rather than integer key location, doesn't increase the time appreciably (then again, I imagine even the element location is a string in Transcript.) -
That's because they're associative arrays (as opposed to numeric)... not even a Rev thing- basically it means that every key is located by using a numeric hash on it's key value, but most importantly, they are usually implemented by using some sort of balanced tree structure in memory rather than a sequential block of memory. Essentially what you get is binary search for your data: if you have 2^N keys it takes at most N hops to find your data because the nodes of the tree are sorted and balanced. For the curious or bored, try googling "red black tree algorithm". So for a 10,000 key array you'll get anything you want in between 1 - 14 (2^14 =~ 16,000) quick hops.
If Rev allowed you to pick a numeric array (as opposed to an associative one) then you'd always get your data in one lookup with numeric keys, but keep in mind that the two are pretty different beasts. I suppose it would be handy to be able to have a numeric array and squirrel it away inside of an associative array, but you'd have to do some really serious pounding to make 10 pointer lookups add up to any bothersome speed problem...
FWIW, Brian
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
