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