lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] PDF generation performance


From: Greg Chicares
Subject: Re: [lmi] PDF generation performance
Date: Wed, 7 Feb 2018 23:01:50 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 2018-02-07 21:49, Vadim Zeitlin wrote:
> On Wed, 7 Feb 2018 21:40:46 +0100 I wrote:
> 
> Me>  I think it should be possible to obtain much more than microscopic
> Me> refinements.
> 
>  Just FYI, applying this simple and still not really optimal (because
> operator<<() is very slow on its own) patch:
> 
> ---------------------------------- >8 --------------------------------------
> diff --git a/ledger_text_formats.cpp b/ledger_text_formats.cpp
[...]
> -    std::stringstream interpreter;
> -    std::locale loc;
> -    std::locale new_loc(loc, new comma_punct);
> -    interpreter.imbue(new_loc);

Gospodi, pomiluy! Please tell me we don't really do such a thing.

> speeds the code by 50% for me, i.e. makes it exactly twice faster (status
> bar shows ~6800ms instead of ~13700ms for me) without any non-trivial
> change in the generated output files (they're still different solely
> because the "CreationDate" field in the generated PDFs changes -- I think
> it would be nice to have some way to call wxPdfDocument::SetCreationDate()
> with some fixed date for testing to allow checking for the changes in
> output just using diff, instead of having to use diffpdf as I do now).

We've always used a fixed date in this part of 'ledger_xml_io.cpp':

    // Skip authentication for non-interactive regression testing.
    if(!global_settings::instance().regression_testing())
        {
        authenticate_system();
        }
    else
        {
        // For regression tests,
        //   - use an invariant string as version
        //   - use EffDate as date prepared
        // in order to avoid gratuitous failures.
        LmiVersion = "Regression testing";
        
prep_date.julian_day_number(static_cast<int>(ledger_invariant_->EffDateJdn));
        }

>  I don't necessarily advocate applying the patch above (although neither do
> I see anything really wrong with doing this), but IMO this definitely
> proves my quoted statement in the beginning of this email.

Although value_cast<> doesn't do the same thing (it shows all the
numeric precision it can, instead of rounding), I wonder if some
implementation layer beneath it does exactly what we want here.
Certainly value_cast<> uses the std::stringstream in-and-out trick
only as a last resort, not least because it's shockingly slow.



reply via email to

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