[lmi] Some not very interesting benchmarking results

[Vadim Zeitlin]

 Hello again,

 We also used the opportunity of profiling PDF generation to check the
performance implications of a couple of other things that we had discussed
in the past but never bothered to really measure, so I'd like to share
these results with you.

 The first 2 are completely unsurprising: the effect of using small
performance optimizations in ledger_evaluator is completely unnoticeable.
This applies both to moving maps given to its ctor argument instead of
copying them and to using std::unordered_map<> rather than std::map<> for
the values stored in it. I.e. changing from one version to the other one
doesn't change the total PDF generation time in a measurably significant
way. This was to be expected as both copying the maps and accessing their
elements takes only a tiny part of the total time, but now we can be sure
that this is indeed the case and, at least, that neither of these
optimizations actually makes things worse (which is not inconceivable, see
below). FWIW I still think that it's better to write code in the way it is
written now, i.e. similarly to the grand, and luckily completely obsoleted
by the advent of range-for in C++11, debate about using "it++" or "++it"
for the iterators in the for loop, even if each particular
micro-pessimization doesn't matter, their combined effect might be
noticeable and it's much simpler to write the code in the optimal way from
the beginning rather than try to optimize it later.


 The next result is about an even older outstanding task: we wanted to know
if the use of Boost.Pool in xmlwrapp code, which uses a singleton pool to
optimize allocation of small objects it uses, was worth it, i.e. whether we
would pay any noticeable price in run-time performance if we built xmlwrapp
without Boost being available. And while I won't give all the raw numbers
because they're a bit noisy (but they're available if you'd like to have a
look at them, of course), here the conclusion is that the difference
between the 2 versions is small, but it is quite noticeable in
micro-benchmarks and the version *not* using Boost.Pool is faster,
sometimes significantly so (by up to 30%!).

 So it doesn't really matter much anyhow, because the total time spent in
xmlwrapp code is actually pretty small during any realistic operation, and
most of the time is spent inside libxml2 where I didn't dare to wander, but
we can safely remove Boost.Pool use from xmlwrapp and thus get rid of
another Boost dependency, so I'll do this soon. Ideally I'd like to get rid
of all Boost dependencies in the library, but this means rewriting its
tests to use CATCH instead of Boost.Test (which shouldn't be difficult to
do and would be an improvement because CATCH is just a single header unlike
Boost which is anything but) and to avoid the use of Boost.IOStream which
is used for its zlib-compression support, which is trickier, although I
think that we might, perhaps, just shell out to "gzip" instead. I'm not
really sure it's worth getting rid of Boost as a dependency for the tests
neither, but at the very least we don't need it for building the library
itself.


 Please let me know if you have any questions about all this,
VZ