[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