GNOME Bugzilla – Bug 640293
Use xlocale functions to implement g_ascii_strtod()
Last modified: 2011-09-18 02:49:10 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
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
Interesting idea. Lets pick this up for 2.29
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.
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.
(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...
The following fix has been pushed: e02b062 Use xlocale functions where available
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.