Re: Array or Hash

The underlying implementation is opaque, and you should always expect it to be.

Furthermore, you are basically barking up the wrong tree here. In either case, the variable is an access-method that, given a “key,” conjures up a “value” from some place in memory. No matter how that mapping is done, that won’t be where any “speed loss” comes from. Loss of speed in memory-access can only come from one source: page faults. Perl’s implementors are already acutely aware of this, and have cleverly designed their systems with this in mind. But, you must also be aware of this fundamental issue with regard to how you use their two nifty inventions. Design your algorithms so that the working-set is of a reasonable size, and remains comparatively stable across time.

Replies are listed 'Best First'.
Re^2: Array or Hash by BrowserUk (Patriarch) on Jan 21, 2011 at 18:33 UTC
Loss of speed in memory-access can only come from one source: page faults. Utter drivel.	[reply]
Re^2: Array or Hash by ikegami (Patriarch) on Jan 21, 2011 at 19:06 UTC
The underlying implementation is opaque, and you should always expect it to be. Not really. "Hash", short for "hash table", is a specific algorithm. "Associative array" is the implementation-independent term. Loss of speed in memory-access can only come from one source: page faults. I think you mean cache misses. p5p is indeed aware that cache misses can mess up theoretical performance analysis, but it's hardly the only source of loss of speed. I'm not well versed in this area, but I suspect that it's quite the opposite, that it takes second seat to other macro factors (like quantum physics to newtonian physics). http://queue.acm.org/detail.cfm?id=1814327 is a story where changing the algorithm to reduce cache misses made a big difference. If what you said was true, a linear search would be as fast as the algorithm to which he changed since they're both cache-oblivious.	[reply]