Re: [lmi] upgrade to xmlwrapp-0.6.0

[Greg Chicares]

On 2009-04-23 18:51Z, Vaclav Slavik wrote:
> On Wed, 2009-04-22 at 20:47 +0000, Greg Chicares wrote:
[...]
>> I noticed that, but couldn't measure any improvement with
>>   CPPFLAGS='-DHAVE_BOOST_POOL_SINGLETON_POOL_HPP'
>> in the 'input_test' unit test's timings. Otherwise, I would have
>> added it. But that would still take extra work.
> 
> That's strange, I measure ~40% improvement (I don't remember if it was
> in input_test or only iterators-manipulating subset of it, though) with
> MinGW's gcc-3.4. Did you use 3.4 or 4.3 in your tests? The improvement
> in performance with gcc-4.x is so small it's only observable under
> valgrind, but I did see real difference with 3.4 back when I was working
> on this...

I can't see any such improvement in 'input_test'.

I guessed that I had made a cockpit error the other day, because I tested
an 'mpatrol' build with and without
  CPPFLAGS='-DHAVE_BOOST_POOL_SINGLETON_POOL_HPP'
and noticed no difference even that way. That's quite strange: 'mpatrol'
substitutes its own glacially slow malloc(), and I had to do
  time input_test
in order to get a reading, because every internal test in 'input_test'
overflowed its timer. So usually 'mpatrol' is very effective at slowing
down any part of a program that uses the heap, yet I just didn't see any
boost::pool effect.

But I just rebuilt 'input_test' with and without the singleton-pool macro,
and see no significant difference in run time in five trials of each:

With '-DHAVE_BOOST_POOL_SINGLETON_POOL_HPP':

Overhead:        3829        3843        3866        3800        3859
Read    :     4405949     4312491     4291713     4300212     4297157
Write   :     2731608     2790966     2745468     2750063     2766422
'cns' io:    42857011    43122188    43338471    42930190    43872211
'ill' io:    10823718    10844757    10797583    10795766    10852546

Without '-DHAVE_BOOST_POOL_SINGLETON_POOL_HPP':

Overhead:        4100        4053        3993        3978        4053
Read    :     4344206     4413300     4361628     4364187     4395954
Write   :     2752552     2761995     2759281     2768324     2752696
'cns' io:    43299350    43150739    43407309    42967428    43050671
'ill' io:    10841153    10858614    10841910    10887819    10858402

Median of five runs, with ratios:

                 with     without   ratio
Overhead:        3843        4053    5.2%
Read    :     4300212     4364187    1.5%
Write   :     2750063     2759281    0.3%
'cns' io:    43122188    43150739    0.1%
'ill' io:    10823718    10858402    0.3%

Just in case I flubbed the macro, here's a sample command line; I made sure
all xmlwrapp and xsltwrapp objects were built this way:

/MinGW_/bin/g++  -MMD -MP -MT ait_impl.o -MF ait_impl.d  -c \
  -I /lmi/src/lmi -I [other directories] \
 -DLMI_WX_NEW_USE_SO  -DLIBXML_USE_DLL -DSTRICT    -DWXUSINGDLL -D__WXMSW__ \
 -DBOOST_STRICT_CONFIG  -DHAVE_BOOST_POOL_SINGLETON_POOL_HPP \
 -pedantic-errors -Werror [other '-W' options] \
 -std=c++98 -ggdb -O2   /opt/lmi/third_party/src/libxml/ait_impl.cxx 
-oait_impl.o

Here are the versioned components of the MinGW compiler I'm using:
  binutils-2.16.91-20050827-1.tar.gz \
  gcc-core-3.4.4-20050522-1.tar.gz \
  gcc-g++-3.4.4-20050522-1.tar.gz \
  mingw-runtime-3.8.tar.gz \
  w32api-3.3.tar.gz \
Although somewhat dated, these components are all official releases that
were used widely, and I would have heard if there was a major problem with
any of them. Besides, IIRC, MinGW has always just imported malloc() from
the msw system runtime dll, in which case the compiler version shouldn't
matter. But maybe the version of libstdc++ does matter? I haven't studied
the boost::pool implementation closely.