On 19 April 2014 19:25, Branko Čibej <br...@wandisco.com> wrote: > On 19.04.2014 17:12, Ivan Zhakov wrote: > > On 19 April 2014 16:44, <stef...@apache.org> wrote: > > Author: stefan2 > Date: Sat Apr 19 12:44:07 2014 > New Revision: 1588651 > > URL: http://svn.apache.org/r1588651 > Log: > Reduce the size of an FSFS instance by using temporary pools > for temp. data during fs_open(). > > * subversion/libsvn_fs_fs/fs_fs.h > (svn_fs_fs__initialize_caches): Document that the POOL shall be > used for temporaries only. > > * subversion/libsvn_fs_fs/caching.c > (svn_fs_fs__initialize_caches): Fix the only place where we used > POOL instead of FS->POOL for > something with svn_fs_t lifetime. > > * subversion/libsvn_fs_fs/fs.c > (fs_serialized_init): Document POOL usage that we will now rely on. > (fs_open): Use a SUBPOOL for anything temporary during FS init. > > Just creating subpool for temporary allocation violates pool design > imho. Proper fix would be add scratch pool parameter to > svn_fs_open()/svn_fs_create(). > > Hi Branko,
> Doesn't "violate" it, as such ... there's a balance to be maintained here. I agree about balance, but general idea of pool design that caller controls memory usage of callee. > Adding a scratch-pool parameter means revising the API and propagating the > revision up the call chain to all the places where a meaningful scratch pool > is already available. Sure it's better to do do that in the long run; but > does the change warrant the related code churn now? Consider that there's a > vtable involved here, too. > I still prefer adding scratch_pool: users interested of improved memory usage (like mod_dav_svn) can use new API. Btw memory usage may increase in some cases with subpools: every pool consumes 8k of memory, subpools are not cleared on error in general. So we got 8k memory wasted on error cases. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
