Re: [Monotone-devel] Please review nvm.automate_get_roster

[Thomas Keller]

Am 05.10.2010 13:40, schrieb Stephen Leake:
> Thomas Keller <address@hidden> writes:
> 
>> Please review the above branch. The branch name has not so much in
>> common with the actual implementation anymore, though:
>>
>> * a new file_sizes table has been added which records the size
>>   in bytes of individual files
>> * two new automate commands have been added, get_file_size returns
>>   a single recorded file size, get_extended_manifest_of returns
>>   a format similar to the current roster format, but without the
>>   local node ids. Additionally, the format prints out the recorded
>>   file size for each file node
>> * migration code and tests have been added, some parts of the migration
>>   code were refactored / expanded
>> * documentation and NEWS / UPGRADE was updated as well
> 
> The code and documentation look ok.
> 
> What is the rationale for caching file sizes, as opposed to computing
> them when needed?
> 
> When are they needed?

Patrick answered this one already. Basically its too costly to call
strlen(cmd("automate get_file")) for huge directory listings. Also note
that file sizes are only one half of the thing I needed badly, the other
half are the different mark information (content_mark, path_mark) to
figure out when a certain file was last changed or renamed. Again,
calling get_content_changed in a loop for listings kills performance here.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature