Yeah, it was the hash improvement (in fact, I use that exact algo w/ proxy) as well as the pool enhancements (esp related to fragments) which would be super cool to pull in.
> On Nov 20, 2015, at 6:08 PM, Greg Stein <gst...@gmail.com> wrote: > > On Fri, Nov 20, 2015 at 4:19 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > On Fri, Nov 20, 2015 at 11:14 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > On Fri, Nov 20, 2015 at 2:55 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > >> > >> On Fri, Nov 20, 2015 at 8:00 PM, Jim Jagielski <j...@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 >
