Hey all, I modified the APR pools implementation and logged some data for a run of "svn status" from the trunk of the svn tree. A mix of over 400k operations were performed during the execution of that command. From some other testing, the pool code uses somewhere around 20 msec total for those allocations, and pool creates, clears and destroys.
Digging in for more detail, I wrote a script that produced the following details: Call counts: clear: 22410 create: 22268 alloc: 412109 destroy: 22268 Maximum depth: 25 Maximum single allocation: 32768 Maximum allocs in a pool: 17996 Maximum pool size: 267428 Maximum live pools: 33 Distribution of maximum pool size: [0..49]: 2862 [50..99]: 12443 [100..249]: 6509 [250..999]: 11 [1000..1499]: 28 [1500..1999]: 78 [2000..2999]: 72 [3000..3999]: 28 [4000..4999]: 18 [5000..9999]: 32 [10000..49999]: 178 [50000..199999]: 8 [200000..267427]: 1 Distribution of pool depth: [0..4]: 6629 [5..9]: 967 [10..14]: 11088 [15..19]: 2464 [20..29]: 1120 Distribution of counts [0..4]: 16964 [5..9]: 4272 [10..99]: 757 [100..999]: 197 [1000..19999]: 78 It is interesting to note that the VAST majority of our pools never allocate more than 250 bytes, and have less than 10 total allocations in them. Our pool's parent/child relationship grows as deep as 25 in this particular operation, and a maximum of 33 pools are simultanously live. Note that I only measured pool operation in that 20 msec; in other words, only the apr_palloc() portion of apr_pstrdup(), for example. We could be spending good amounts of unmeasured time copying memory around. Cheers, -g
