Pools overhead, WAS: RE: svn commit: rev 7166 - trunk/subversion/libsvn_fs

[Sander Striker <st...@apache.org>]

> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Wednesday, September 24, 2003 2:12 PM

[...]
> I believe that pool creation is not nearly as cheap as a simple alloc.
> Sander can correct me here, though.

It depends.  The commandline client creates it's own allocator without a
mutex, meaning that there will be no locking during allocation nor pool
creation/destruction.  We can safely do this since we know the cmdline
client is single threaded.  mod_dav_svn benefits from httpd's tuned pools
usage (different per mpm).

In cases where there is a mutex*, the cost of a pool creation in the worst
case is:

  - lock
  - check to see if there is a block on our freelist, and realize there is none
  - unlock
  - malloc a new block
  - turn the block into a pool
  - lock
  - add pool to parent child list
  - unlock

The cost for a destroy is the same, but in reverse (and ofcourse no malloc(), and
usually no free()).


Sander

*) Untuned clients for example.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org