On Jul 30, 2009, at 10:05 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> 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.
People who care about the bindings are welcome to ensure that they are
updated. (That group of people does not directly include me, fwiw.)
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377199
Received on 2009-07-31 05:07:39 CEST