> 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 > > > >
