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