After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 640293 - Use xlocale functions to implement g_ascii_strtod()
Use xlocale functions to implement g_ascii_strtod()
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.27.x
Other All
: Normal enhancement
: 2.30
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-01-22 21:22 UTC by Yeti
Modified: 2011-09-18 02:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
initial patch (4.69 KB, patch)
2011-02-16 02:22 UTC, Matthias Clasen
none Details | Review
Use xlocale functions where available (4.99 KB, patch)
2011-09-18 02:49 UTC, Matthias Clasen
committed Details | Review

Description Yeti 2011-01-22 21:22:18 UTC
Function g_ascii_strtod() is quite complicated and expensive.  It analyses the current locale and then tries to convert a C-locale number representation to the current locale; this typically involves memory allocation and stuff.

On a modern POSIX system, this including GNU and OS X at this moment (AFAIK), the same effect is achieved by (approximately, this init is clearly thread-unsafe):

=====================================
#include <xlocale.h>

...

static locale_t C_locale = NULL;

if (!C_locale)
    C_locale = newlocale(LC_ALL, "C", NULL);

return strtod_l(string, &endptr, C_locale);
=====================================

Note: OS X manpages suggest to use NULL second argument of newlocale() to achieve the C locale while GNU wants an explicit "C".  I don't have a Mac but I suppose explicit "C" would work there too.

The xlocale functions are not documented yet on GNU but they are present see also http://sourceware.org/bugzilla/show_bug.cgi?id=10891
Comment 1 Yeti 2011-01-23 14:49:46 UTC
A simple efficiency comparison: the time to read 1000000 floating point numbers (on my notebook):

strtod_l in any global locale:  330 ms
g_ascii_strtod in C:            430 ms
g_ascii_strtod in de_DE.UTF-8:  630 ms
Comment 2 Matthias Clasen 2011-01-28 01:32:43 UTC
Interesting idea. Lets pick this up for 2.29
Comment 3 Matthias Clasen 2011-02-16 02:22:15 UTC
Created attachment 180958 [details] [review]
initial patch

Here is a patch which uses strtod_l, strtoll_l and strtoull_l - unfortunately, there seems to be no printf_l. 

What this needs most is some more thorough tests.
Comment 4 Matthias Clasen 2011-02-16 02:40:22 UTC
Actually, looks like all the _l functions are BSD and not in POSIX, but that should not keep us from using them where they exist.
Comment 5 Yeti 2011-02-16 09:02:58 UTC
(In reply to comment #4)
> Actually, looks like all the _l functions are BSD and not in POSIX, but that
> should not keep us from using them where they exist.

Hm, you are right, POSIX:2008 actually defines only the locale_t management functions (uselocale, duplocale, ...) and some elementary _l functions such as islower_l so the rest is vendor extensions.  But since their presence needs to be tested anyway...
Comment 6 Matthias Clasen 2011-09-18 02:49:06 UTC
The following fix has been pushed:
e02b062 Use xlocale functions where available
Comment 7 Matthias Clasen 2011-09-18 02:49:10 UTC
Created attachment 196861 [details] [review]
Use xlocale functions where available

Implement g_ascii_strto{d,ll,ull} and g_ascii_formatd using
xlocale functions where available. This is slightly faster
and a lot less icky than our homegrown code.