This is addressed to the participants of this conversation in general:
I think getting to discussions of O(1) or whatever is a bit much for a
language like Perl. It's not designed for speed, though speed is
certainly nice to have. It's also got a fantastic (well, it's got a
bit of a learning curve) interface to achieve really blisteringly fast
code - XS, and any number of the foreign function interfaces people
have been contributing to CPAN over the years.
Choosing array-based parameterization instead of hashes seems to be a
bad idea to me, because you could potentially end up with lots of
cases of sparse arrays. And while it's nice to have typo detection, it
does limit your extensibility, as was conceded earlier.
So, if you really need these types of things - like strict typing or
checking of each hash field name to ensure you're doing the right
thing - perhaps you are using the wrong language. Then again, I can
definitely see the usefulness of a module like Tie::Hash::Autovivify
when trying to track down bugs, but personally I wouldn't want the
added overhead of that sort of checking on each hash call (especially
since TIEd interfaces are known to be slow, or at least widely
believed thus).
@David, I had always thought that if you do something like:
if ($ENV{TEST_HASH_KEYS}) {
require Test::Hash::Autovivify;
tie %hash ...
}
else {
%hash = ();
} # for accomplishing some sort of end-user debug mode
Then everything should just work, and you wouldn't be losing
performance. You could also just "use" the Autovivify module (if it's
available) as part of your functionality testing, which would be in
your test .t files if you are distributing on CPAN (and potentially
also if you are not).
Anyway, my point is: to each their own, and profiling is more
important than Big Oh notation. This is just one of the many things I
have been upset with the treatment of in my Computer Science
program--it's way too academic, and not applied enough, but I suppose
that's University in general.
When it comes down to it, everything in software or really, most
fields, is that it comes to some sort of trade-off. You've got the
classic time-space tradeoff, and then the programmer time vs
application runtime tradeoff, and so on and so forth. Perl has always
seemed to me a language where you can quickly hack things together to
get the job done, and refine the code if and when it becomes necessary
to do so. To that end, there are some nice modules to test code
coverage, profiling, memory leaks, etc.
Cheers,
Jonathan Yu
On Tue, Mar 3, 2009 at 7:41 AM, David Cantrell <da...@cantrell.org.uk> wrote:
> On Mon, Mar 02, 2009 at 08:22:24PM +0000, Nicholas Clark wrote:
>
>> Hash lookup should be O(1), independent of number of keys. Of course, a hash
>> with more keys uses more memory, but so does an array with more elements.
>
> But that's a bigger value of 1 from that required for an array lookup.
>
> --
> David Cantrell | Enforcer, South London Linguistic Massive
>
> When one has bathed in Christ there is no need to bathe a second time
> -- St. Jerome, on why washing is a vile pagan practice
> in a letter to Heliodorus, 373 or 374 AD
>
