Jerry Hedden wrote:
> 1. Speed - retrieving the TID is faster than generating a
> 'threads=SCALAR(0x100110ec)' string.
I did the tests: This is a 5X (i.e. 400%) speed improvement!!!
> 2. More speed - the shorter the hash key the faster the
> lookup. (Yes, I've tested this. The more characters in the
> key, the more cycles it takes to compute the hash for that
> key.)
And this is a 30% speed improvement!
Joshua ben Jore wrote:
> I'm asking you to choose.
I thought my choice was obvious: Stringification.
> Objects that stringify to something that looks like a
> number sucks in the general case.
Define 'in the general case'. From all you've said, your
very narrow world view is the demand that 'p $thr' in a
debugger print out 'threads=SCALAR(0X0123ABCD)' because
you're too lazy to type 'p overload::StrVal($thr)'. This is
hardly 'the general case'.
> Anyway, why are you using overloading if you care about
> speed? I never bench marked it myself to see the
> difference but I've gotten the impression that just having
> this present in the class makes doing anything with the
> object slower. For sure I've noticed a whole heap of
> additional ISA walking when I've instrumented that on
> overloverloaded objects.
Unlike you, I did do the tests, and the overloading only
costs 7% which is in the grass compared with the other
improvements reported above.
The bottom line in that $hash{$thr} and "$thr" are both more
than 5 times faster with ""-overloading than without it.
Jerry D. Hedden continues:
> 3. Suscinctness - $hash{$thr} as opposed to $hash{$thr->tid}.
>
> 4. Intuitiveness - print("Thread $thr started...\n");
Joshua ben Jore retorts:
> Bah. This is anti-intutive. To me anyway.
Well, then on this one last point I suppose we can only
agree to disagree.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
