Following Andreas ReadStream>>nextFloat track, I did improve 
SqNumberParser speed too, just for fun.

With minor changes, a speed factor > 2 in Float crunching has been achieved.
I could not reach Andreas efficiency, though.
SqNumberParser is still 2 to 4 times behind.

A difference is that SqNumberParser does return the nearest floating 
point value, while ReadStream>>nextFloat does return an approximate. 
This explains some of the bad scores of the former which cannot avoid 
LargeInteger arithmetic when the latter does (cases of exponent with 
high values).

This can be marginally improved with timesTwoPower: trick in the 
Fraction case, which would sometimes avoid LargeInteger arithmetic.
But the implications with Float overflow and underflow must be handled, 
and it's not really worth...

Remaining performance is mostly explained by method inlining, which is 
not desirable in SqNumberParser. It could however be subclassed with an 
OptimizedSqueakFloatParser (I did not...).

Experiments are at http://bugs.squeak.org/view.php?id=6976 if anyone 
interested.

I remind there are also tricks that SqNumberParser uselessly deals with 
like:
| s |
s := '1' , (String new: 400 withAll: $0) , '.1e-400'.
{s readStream nextFloat. SqNumberParser parse: s readStream. Number 
readFrom: s readStream}.

Last thing, speeding up Float reading is not premature optimization, 
large files made of formatted Float are widely used in some areas.
Sure an atof() primitive would probably outperform if that really matters...

Nicolas