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

Re: Remove entries cache in adm_access

From: Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA_at_GMail.Com>
Date: Fri, 31 Jul 2009 05:05:34 +0200

2009-07-31 04:48:06 Hyrum K. Wright napisaƂ(a):
> Greg,
> The doc string for svn_wc_entries() reads thusly:
> /** Parse the `entries' file for @a adm_access and return a hash @a
> entries,
> * whose keys are (<tt>const char *</tt>) entry names and values are
> * (<tt>svn_wc_entry_t *</tt>). The hash @a entries, and its keys and
> * values, are allocated from the pool used to open the @a adm_access
> * baton (that's how the entries caching works). @a pool is used for
> * transient allocations.
> ...
> We've discussed before that removing the entries cache in adm_access
> will lead to memory explosion, as the entries are re-read from disk
> into the access pool, without ever freeing memory used for stale
> entries hashes. (Well, it will lead to *faster* memory explosion,
> since we still flush the cache under certain circumstances.)
> However, as we start touching the sqlite db directly, the cache
> becomes stale quite quickly, since the entries hash isn't modified at
> the same time the the db is, has happens with
> svn_wc__entries_modify(). Since we're not using adm_access anymore,
> we've no way of knowing when to flush the cache, which means we'll
> need to flush it aggressively--so aggressively that it probably isn't
> worth keeping the cache around.
> As for API consumers which are using entries and now have sub-optimal
> memory consumption, I say "tough rocks, upgrade to the new APIs".
> That might be harsh, but I think it's the reality as keeping the cache
> in sync is much more trouble than it's worth.
> Thoughts?

If you update API consumers in our bindings, then +1.

Arfrever Frehtes Taifersar Arahesis

Received on 2009-07-31 05:04:41 CEST

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