[PATCH] unify itoa
Rob Landley
rob at landley.net
Wed Jul 12 15:58:37 UTC 2006
On Wednesday 12 July 2006 10:08 am, Denis Vlasenko wrote:
> > Ran that under "time", and got 0.707 seconds. 1000000/.707 is 1.4
> > million
>
> Got 0.944 seconds here.
So you're in the neighborhood of a million conversions a second even with the
bounds checking added. You were previously talking about 1/20th that many
conversions per second. Congratulations, we just sped it up by a factor of
twenty without actually doing anything.
> Let's use the below one which is 1.5 faster on i386,
And yet that's still not fast enough. Fast enough for what? I am aware that
we could hand code it in assembly (which isn't much uglier than bit-shifting
a long long magic constant), but I'm really not interested without a good
reason.
What, exactly, are you doing that's too slow, and what makes you think that
_this_ code is this bottleneck? This is not a "we can do better" when the
end result is bigger and harder to understand.
> has bound checking
> and truncates most significant digits if buffer is too small, not least
> significant ones:
I added bounds checking back on the 10th (svn 15683).
If you truncate it doesn't get the correct result no matter what you do, but
the current behavior is the _expected_ behavior, it's what you get with
snprintf() and safe_strcpy(), and everything else I'm aware of that does
bounds checking. If you want just the lower digits, you can always do a
modulus before calling itoa().
> Please apply the attached patch.
No.
Rob
--
Never bet against the cheap plastic solution.
More information about the busybox
mailing list