[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.
- Re: [lmi] Another compiler upgrade, (continued)
- Re: [lmi] Another compiler upgrade, Greg Chicares, 2018/04/08
- [lmi] PATCH: Upgrade xmlwrapp to 0.9.0 (was: Another compiler upgrade), Vadim Zeitlin, 2018/04/10
- Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0, Greg Chicares, 2018/04/10
- Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0, Vadim Zeitlin, 2018/04/11
- Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0, Greg Chicares, 2018/04/11
- Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0, Vadim Zeitlin, 2018/04/11
- Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0, Greg Chicares, 2018/04/11
- Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0, Vadim Zeitlin, 2018/04/11
- Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0, Greg Chicares, 2018/04/11
- Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0, Vadim Zeitlin, 2018/04/11
- Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0,
Greg Chicares <=
- [lmi] VCS caching [Was: PATCH: Upgrade xmlwrapp to 0.9.0], Greg Chicares, 2018/04/11
- Re: [lmi] VCS caching, Vadim Zeitlin, 2018/04/11
- Re: [lmi] VCS caching, Greg Chicares, 2018/04/13
- Re: [lmi] VCS caching, Vadim Zeitlin, 2018/04/13
- Re: [lmi] VCS caching, Greg Chicares, 2018/04/13
- Re: [lmi] VCS caching, Vadim Zeitlin, 2018/04/13
- Re: [lmi] VCS caching, Greg Chicares, 2018/04/13
- Re: [lmi] VCS caching, Greg Chicares, 2018/04/13
- Re: [lmi] VCS caching, Vadim Zeitlin, 2018/04/13
- Re: [lmi] VCS caching, Greg Chicares, 2018/04/14