lmi
[Top][All Lists]
Advanced

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]