memory statistics

[Greg Stein <gs...@gmail.com>]

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