Re: Performance improvements for src/port/snprintf.c
От | Andres Freund |
---|---|
Тема | Re: Performance improvements for src/port/snprintf.c |
Дата | |
Msg-id | 20180927004022.lfhffbj3roxzf5ca@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Performance improvements for src/port/snprintf.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Performance improvements for src/port/snprintf.c
|
Список | pgsql-hackers |
On 2018-09-26 20:25:44 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2018-09-26 19:45:07 -0400, Tom Lane wrote: > >> No, there are no additional layers that weren't there before --- > >> snprintf.c's snprintf() slots in directly where the platform's did before. > > > Hm? What I mean is that we can't realistically be faster with the > > current architecture, because for floating point we end up doing glibc > > sprintf() in either case. > > Oh, you mean specifically for the float conversion case. I still say > that I will *not* accept judging this code solely on the float case. Oh, it should definitely not be judged solely based on floating point, we agree. > The string and integer cases are at least as important if not more so. I think the integer stuff has become a *little* bit less important, because we converted the hot cases over to pg_lto etc. > >> Interesting. strfromd() is a glibc-ism, and a fairly recent one at > >> that (my RHEL6 box doesn't seem to have it). > > > It's C99 afaict. > > It's not in POSIX 2008, and I don't see it in my admittedly-draft > copy of C99 either. But that's not real relevant -- I don't see > much reason not to use it if we want a quick and dirty answer for > the platforms that have it. Right, I really just wanted some more baseline numbers. > If we had more ambition, we might consider stealing the float > conversion logic out of the "stb" library that Alexander pointed > to upthread. It says it's public domain, so there's no license > impediment to borrowing some code ... Yea, I started to play around with doing so with musl, but based on early my benchmarks it's not fast enough to bother. I've not integrated it into our code, but instead printed two floating point numbers with your test: musl 5000000 iterations: snprintf time = 3144.46 ms total, 0.000628892 ms per iteration pg_snprintf time = 4215.1 ms total, 0.00084302 ms per iteration ratio = 1.340 glibc 5000000 iterations: snprintf time = 1680.82 ms total, 0.000336165 ms per iteration pg_snprintf time = 2629.46 ms total, 0.000525892 ms per iteration ratio = 1.564 So there's pretty clearly no point in even considering starting from musl. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: