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

> 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
Received on Wed Sep 24 16:28:37 2003