lmi
[Top][All Lists]
Advanced

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

Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0


From: Greg Chicares
Subject: Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0
Date: Wed, 11 Apr 2018 23:03:23 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 2018-04-11 22:44, Vadim Zeitlin wrote:
> On Wed, 11 Apr 2018 18:11:11 +0000 Greg Chicares <address@hidden> wrote:
> 
[...xmlwrapp dependencies on boost...]
> GC> 
> GC> I was really looking forward to removing all boost dependencies.
> GC> IIRC, xmlwrapp uses only boost's "singleton pool", and only if
> GC> it's available. IOW, it's an optional optimization, so this
> GC> doesn't stand in the way of eliminating boost--true?
> 
>  Yes, use of Boost.Pool is optional. I don't know how important of an
> optimization it is, considering the number of small allocations in the code
> (e.g. each node needs one), I think it might well be however. Would it be
> useful to (a) write a benchmark testing how much memory/time is used when
> loading a biggish XML document and run it with and without the pool and (b)
> replace Boost.Pool with a manual allocator if the results differ
> significantly? Please let me know if you'd like me to do this.

Yes, that sounds like a good idea: any decision we make without
evidence may turn out to be regrettable and costly.

>  BTW, it does bother me that the tests need to be disabled due to lack of
> Boost.Iostream, but replacing this one isn't trivial as it's used for its
> gzip support and, having recently added xz support to wx streams, I know
> that doing the same thing using zlib is definitely possible, but not
> especially appealing...

lmi doesn't need to run each library's tests. For libxml2, I think
we skip them; the same is probably true of libxslt and liblzma.
We never run any of boost's own tests; the same is true for every
other library installed with 'install_miscellanea.make'.

That doesn't mean it's a bad idea to run packages' own tests.
It just means we've never done it, and that has never been a
problem in twenty years.

But let's step back and look at the pool and iostreams questions
in a different way. We are close to removing all use of boost in
lmi itself. Once we've done that, we can remove boost from
'install_miscellanea.make'. And then there's no point in freezing
the boost version at 1.33.1 any more: a new day dawns, and we can
consider limited use of boost outside of lmi proper, though I'm
reluctant to reintroduce a dependency on it.



reply via email to

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