On 15.11.2010 23:22, Gavin Beau Baumanis wrote:
> Ping. This has received no further comments.
>
>
>
> Gavin "Beau" Baumanis
> E: gavinb_at_thespidernet.com
>
>
> On 31/10/2010, at 12:42 PM, Daniel Shahaf wrote:
>
>> Is there a reason not to apply this "let's not reinvent the wheel" patch?
>>
>> [[[
>> Index: subversion/libsvn_fs_fs/fs_fs.c
>> ===================================================================
>> --- subversion/libsvn_fs_fs/fs_fs.c (revision 1029231)
>> +++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
>> @@ -2205,15 +2205,14 @@ read_rep_offsets(representation_t **rep_p,
>> return SVN_NO_ERROR;
>> }
>>
>> -/* Combine the revision and offset of the ID to a string that will
>> - * be used as a cache key. Allocations will be made from POOL.
>> +/* Return a string that uniquely identifies the noderev with the
>> + * given ID, for use as a cache key.
>> */
>> static const char *
>> get_noderev_cache_key(const svn_fs_id_t *id, apr_pool_t *pool)
>> {
>> - return svn_fs_fs__combine_two_numbers(svn_fs_fs__id_rev(id),
>> - svn_fs_fs__id_offset(id),
>> - pool);
>> + const svn_string_t *id_unparsed = svn_fs_fs__id_unparse(id, pool);
>> + return id_unparsed->data;
>> }
>>
>> /* Look up the NODEREV_P for ID in FS' node revsion cache. If noderev
>> ]]]
>>
>> (It does not resolve my test failures.)
>>
>> Daniel
It turns out that this function is called rarely if the cache
hit rate is high. If it is low, the extra cost for id_unparse
won't be noticeable as well in comparison to the costs
of fetching the info from the file.
Committed as r1035882.
-- Stefan^2.
Received on 2010-11-17 01:44:56 CET