[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] [lmi-commits] master e8d4b982 08/11: Measure ledger_format() s
From: |
Greg Chicares |
Subject: |
Re: [lmi] [lmi-commits] master e8d4b982 08/11: Measure ledger_format() speed |
Date: |
Sat, 30 Apr 2022 16:45:35 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 |
On 4/30/22 14:54, Vadim Zeitlin wrote:
> On Fri, 29 Apr 2022 11:59:33 -0400 (EDT) Greg Chicares
> <gchicares@sbcglobal.net> wrote:
>
> GC> [...commit e8d4b982b2769...] Measure ledger_format() speed
>
> I'd be curious (but not curious enough to do it without you telling me
> that it would be useful)
It would indeed be useful.
> to benchmark it with C++20 format library. It has
> support for using separators, see https://fmt.dev/latest/api.html#locale
I'm not averse to this. I had looked into it a while ago, and concluded
that Zverovich did a really good job.
> (this is a link to fmt documentation just because it has a nice example,
> but the standard library works in the same way, at least in the recent
> enough implementations to include it)
AFAICT, the github reference implementation is pretty much identical
to C++20's std::format.
> and AFAIK it's much faster than
> snprintf(), let alone C++ stream insertion operators that were designed to
> be as slow as possible.
You speak hyperbolically, of course, in that slowness was an accident
rather than a goal; but I was very surprised to see how much faster it
has become, compared to snprintf().
> Of course, the real reason I keep brining fmt up is that it's so much more
> convenient to use (and not just faster and safer) -- once you get used to
> using it, going back to C++ streams is just horrible. And while I don't
> think we can rely on std::format() being available in MinGW version that we
> use, using standalone fmt is trivial (it's header-only)
The documentation
https://fmt.dev/latest/usage.html
says it's just a matter of copying some code that seems to have a
GPL-compatible license--depending on where you look, either it's just
three headers, or three headers plus a TU that appears to require cmake,
though perhaps that's already scripted.
> and we could start
> using it right now and switch to the standard library without changing
> anything in the code when it becomes available there.
Sounds promising.
And right now I know where most of the formatting code is. Or I
will, after we test those recent changes and find anything I missed.