apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Optimization, modern C and APR 2.0 onwards
Date Fri, 20 Nov 2015 23:08:55 GMT
On Fri, Nov 20, 2015 at 4:19 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:

> On Fri, Nov 20, 2015 at 11:14 PM, William A Rowe Jr <wrowe@rowe-clan.net>
> wrote:
> > On Fri, Nov 20, 2015 at 2:55 PM, Yann Ylavic <ylavic.dev@gmail.com>
> wrote:
> >>
> >> On Fri, Nov 20, 2015 at 8:00 PM, Jim Jagielski <jim@jagunet.com> wrote:
> >> > If we are serious about having a serious update to APR, I
> >> > would recommend that we use more up-to-date data structures,
> >> > patterns and algorithms than those in apr1. For example,
> >> > Greg's pocore mini lib is an example of the types of improvements
> >> > we should consider.
> >>
> >> Could you share a pointer to it please?
> >
> >
> > https://github.com/gstein/pocore
>
> Thanks!
>

Jim may have other items in mind, but I believe its notable improvements
are:

* hash tables built upon modern research
* pools that avoid long-term memory fragmentation, including free()
capability
* structured error handling

As a solid test of the pocore library, I patched APR to use pocore's pools
and hash tables (see apr/branches/gstein-pocore/) and then ran Subversion's
extensive test suite. Except for tests depending upon hash table iteration,
I got it all working just fine. pocore's pools are faster than APR (tho
both are screaming fast, in the scheme of things), APR pools on top of
pocore kinda slowed down the tests :-P

I'd be more than happy to discuss its design, both now and future direction
(eg. memory coalescing is intended, but not yet implemented).

Cheers,
-g

Mime
View raw message