

<HTML><BODY><P>Float to string conversion is very slow when dealing with high-order numbers. Conversion time is almost linearly increases with exponent.</P>

<P>Test case [i386/Win32,"ValReal=extended"]: converting 1000000 numbers into default exponential format by "writeln(them)" to dev/nul.<BR><BR>"1.2345678901234568E+3999": FPC=79.72 seconds, Delphi=0.71 seconds<BR>"1.2345678901234568E-3999": FPC=35.88 seconds, Delphi=0.67 seconds</P>

<P>Side note: negative exponents are handled by FPC about 2 times faster than positive ones.</P>

<P>The problem lies in float to string conversion routine str_real() [rtl/inc/real2str.inc].</P>

<P>Current implementation uses several loops of the form "while <not done> do d:=d*10" or equivalents, so the simple fix is not possible without significant procedure rework.</P>

<P>There is a non-invasive workaround to improve performance without making major changes in the algorithm itself -- an artificial reduction of the exponent before performing the conversion (see attached diff). But I'm not sure this will not introduce some artifacts in conversion.</P>

<P>Anyway, I ran that diff on the same conditions as above. Full test suite did not show any regressions. My test case resulted in:<BR><BR>"1.2345678901234568E+3999": FPC=1.92 seconds<BR>"1.2345678901234568E-3999": FPC=1.83 seconds<BR><BR>so its timing is still about 2.5 times slower than Delphi, but much better then before.</P>

<P>Can anyone review or test suggested changes before creating Mantis entry?</P>

<P>In particular, I'm not sure what the last line of the patch is placed correctly ("inc(correct,high_exp10_reduced);"). Ideally this operation could be performed when "E.." is emitted, but there is another branch for "f<0" for fixed precision, which is hard to understand for me of how incorporate this additional exponent shift (possibly, it's too late to do something like this?..).</P>

<P>---<BR> WBR, Max.<BR></P></BODY></HTML>