> On Fri, 2001-08-24 at 13:50, Sander Striker wrote:
> > Please hlod off for a day. I've done some pools coding
> > too again (and hopefully I can send in a patch tonight).
> > It should have even better performance. Just ironing it
> > out.
> >
> > Thanks,
> >
> > Sander
> >
> sander,
> could your and brian's patches be merged, or do they both basiclaly
> do the same thing.
Mine takes it a bit further. It essentially makes the freelist more
efficient. Adds the possibility to request a new freelist for a pool,
which can optionally have locking. Furthermore it resolves some
issues with possible segfaults in the current pools code when running
out of memory.
However, there is a downside. I started with an empty slate and then
started to add things in. I still haven't merged some things over
(the APR_POOL_DEBUG mode, USE_MALLOC and other fancy debug stuff). Also,
my code isn't documented very well at the moment (OTOH, the current
pools code isn't exactly a quick read with all those #if[def] lines...).
Sander
> >
> > > -----Original Message-----
> > > From: Ian Holsman [mailto:[EMAIL PROTECTED]]
> > > Sent: 24 August 2001 21:14
> > > To: [EMAIL PROTECTED]
> > > Subject: [Fwd: brianp patch Quantify results] (was
> thread-specific free
> > > listfor pools" patch )
> > >
> > >
> > > One of our other developers ran Brian Pane's
> > > thread-specific free list for pools patch (posted ~1 week ago)
> > >
> > >
> > >
> > > here are his results.
> > > ...Ian
> > >
> > > -----Forwarded Message-----
> > > From: Blaise Tarr <XXXXXXXXXX>
> > > To: [EMAIL PROTECTED]
> > > Subject: brianp patch Quantify results
> > >
> > >
> > > Hey,
> > >
> > > For the baseline I used the CVS version from yesterday (8/3) morning.
> > > Then I applied Brian's "thread-specific free list for pools" patch.
> > >
> > > I used these configs:
> > > StartServers 1
> > > MaxClients 1
> > > MinSpareThreads 5
> > > MaxSpareThreads 10
> > > ThreadsPerChild 25
> > >
> > > For the test, I requested 500 news.com pages that have 2 virtual
> > > includes. The pages were copies of the same file but had different
> > > names. (lynx -source http://hungry.cnet.com/2file/00${i}.html)
> > >
> > > handle_include + descendants were 9.5% faster with Brian's patch, and
> > > accounted for 5.89% of the total time, as opposed to 6.28% of the
> > > total time for the baseline. Overall, Brian's patch reduced the
> > > number of cycles by 3.74%.
> > >
> > > Now, I must add that these are Quantify numbers, not real world
> > > numbers.
> > > So, what's next?
> > >
> > > --
> > > Blaise Tarr
> > > XXXXXXXXXXXXXXX CNET.com
> > > 908.541.3771 The source for computers and technology.
> > >
> > >
> > >
> > >
> --
> Ian Holsman [EMAIL PROTECTED]
> Performance Measurement & Analysis
> CNET Networks - (415) 364-8608
>
>
>
>
