[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [serf-dev] Re: What stands between us and branching 1.7?

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: Mon, 24 Jan 2011 08:20:55 +0100

On Sun, Jan 23, 2011 at 8:39 PM, Justin Erenkrantz <justin_at_erenkrantz.com>wrote:

> On Sun, Jan 23, 2011 at 10:22 AM, Lieven Govaerts <svnlgo_at_mobsol.be>
> wrote:
> > Things have changed since then though. Can anyone test with svn 1.6.x to
> see
> > how it uses memory?
>
> For ra_serf, I'm wondering if we're creating an additional pool that
> isn't necessary - namely the editor_pool.
>
> I've done some light testing with the ra_serf patch below, which does
> the following things:
> - Create a separate pool hierarchy for files
> - Combines the per-file editor pool with the regular pool for file
>
> For serf itself, I've also switched zlib to use the bucket allocator -
> which also helps which churn - as every call to inflateInit/inflateEnd
> invokes malloc/free - so we can save on that quite bit.
>
> Overall, this seems to reduce the amount of 20KB allocations
> substantially...but not sure it does much to the overall memory usage.
>
> Not sure if/when I'll pick this up again...so patches below if someone
> else wants to run with it. -- justin
>
> Index: update.c
> ===================================================================
> --- update.c (revision 1062462)
> +++ update.c (working copy)
> @@ -107,6 +107,7 @@
> /* controlling dir baton - this is only created in open_dir() */
> void *dir_baton;
> apr_pool_t *dir_baton_pool;
> + apr_pool_t *file_pool;
>
> /* Our master update editor and baton. */
> const svn_delta_editor_t *update_editor;
> @@ -202,9 +203,6 @@
> /* The properties for this file */
> apr_hash_t *props;
>
> - /* pool passed to update->add_file, etc. */
> - apr_pool_t *editor_pool;
> -
> /* controlling file_baton and textdelta handler */
> void *file_baton;
> const char *base_checksum;
> @@ -403,7 +401,7 @@
> report_info_t *new_info;
>
> new_info = apr_pcalloc(info_parent_pool, sizeof(*new_info));
> - apr_pool_create(&new_info->pool, info_parent_pool);
> + apr_pool_create(&new_info->pool, info->dir->file_pool);
> new_info->file_baton = NULL;
> new_info->lock_token = NULL;
> new_info->fetch_file = FALSE;
> @@ -500,6 +498,7 @@
> if (dir->base_name[0] == '\0')
> {
> apr_pool_create(&dir->dir_baton_pool, dir->pool);
> + apr_pool_create(&dir->file_pool, dir->pool);
>
> if (dir->report_context->destination &&
> dir->report_context->sess->wc_callbacks->invalidate_wc_props)
> @@ -519,6 +518,7 @@
> SVN_ERR(open_dir(dir->parent_dir));
>
> apr_pool_create(&dir->dir_baton_pool,
> dir->parent_dir->dir_baton_pool);
> + dir->file_pool = dir->parent_dir->file_pool;
>
>
Linking the file pool to the pool of its parent dir has resulted in crashes
earlier. I seem to remember it's because the files are received after the
dir is already closed in the editor drive, but I don't remember all the
details.

Lieven

[..]
Received on 2011-01-24 08:21:55 CET

This is an archived mail posted to the Subversion Dev mailing list.