183418 - PR_strtod is > 50% slower than strtod

Status: RESOLVED WONTFIX

(NSPR :: NSPR, defect)

Description

[Daniel Bratell]

While working on bug 165877 I noticed that PR_strtod is slower than the libc
strtod. Shouldn't be necessary.

Comment 1

[Wan-Teh Chang]

I may not be able to do anything about this.

PR_strtod is based on Dr. David Gay's dtoa.c.
I suggest that you report this performance issue
to him.  He is the real owner of this piece of
code.

PR_strtod was originally added for Javascript.
Later Javascript made its own copy of prdtoa.c
(jsdtoa.c).  So you should definitely file a
bug against Javascript about JS_strtod.

Brendan Eich should know why Javascript needed
its own implementation of strtod.  It is
possible that full conformance to some floating
point standard is more important than performance.

Comment 2

[Alfred Kayser]

Is PR_strtod still required?
Javascript seems to use their own edition anyway.
Most platforms do have a valid strtod themselves.
In the CSS scanner ToFloat (wrapper to PR_strtod) is used and it does
measurably impact the performance of the scanner (bug 311566).

Comment 3

[Wan-Teh Chang]

I can't remove the PR_strtod function from the NSPR library
because it'll break backward compatibility.

Since I don't know floating point numbers well, I am not sure
if I can change the implementation of PR_strtod, for example,
to simply call the Standard C Library function strtod.  I am
worried that some NSS customers might rely on certain properties
of the current PR_strtod implementation (Dr. David Gay's dtoa.c).

I did verify that strtod and PR_strtod have the same function
prototype, so strtod is a drop-in replacement for PR_strtod.
So, it is best for applications that use PR_strtod to decide
whether they should switch to strtod.

Comment 4

[Wan-Teh Chang]

I just wanted to add that I expect most PR_strtod users
to be able to switch to strtod without problems.