Re: Hex to NSString or NSData
Re: Hex to NSString or NSData
- Subject: Re: Hex to NSString or NSData
- From: Gwynne Raskind <email@hidden>
- Date: Sat, 9 May 2009 22:33:58 -0400
On May 9, 2009, at 10:20 PM, Greg Guerin wrote:
Yeah, but since that was only done as part of a benchmark, it
didn't much matter. It may have skewed the numbers upwards
unnecessarily, but wouldn't have changed their relation to each
other since the same sequence was calculated for all three versions.
It changes the validity of terms like "by a factor of about two"
because you haven't accounted for the overhead costs properly. The
overall times differ by a factor of two, but the code under test may
not be faster by a factor of two.
Given the data:
t(overhead) + t(c1) = t1
t(overhead) + t(c2) = t1/2
This does not imply t(c1) equals t(c2)/2, unless t(overhead) is 0.
The % may still not matter much, but you can't infer it from the
reported data.
Can you suggest a means to account for the overhead? I used i % 255
because passing a constant value to any of these functions would only
have tested a single code path in the switch and if-else forms. (It's
worth noting that there IS only one code path in the lookup table
form, i.e. there are no branches, which offers one explanation for its
speed.) I could have passed i by itself without the modulus, but I
wasn't sure off the top of my head whether that would exercise all the
code paths either :).
-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden