[RFC] question about different behavior of WorkingTree.iter_changes

Alexander Belchenko bialix at ukr.net
Fri Apr 11 13:24:56 BST 2008


Attached patch allow me to partially reproduce this problem
with bzr.dev 3359. Running bzr status in the patched branch
I've got this numbers:

python bzr --no-plugins --no-aliases st
time: 1.406 sec.

python bzr --no-plugins --no-aliases st -S
time: 2.156 sec.

But these numbers do not explain why my code behaves so differently
for --short/--no-short.


Alexander Belchenko пишет:
> I'm working hard to finish my line-endings support work ASAP.
> I started dogfooding my version and found one unpleasant
> performance drawback. Execution time of status command
> significantly different depends on --short option.
> 
> Here the numbers for standard bzr.exe 1.3 running st and st -S
> in my eol working branch. There is 3 unknown files and 1 modified.
> I ran each test 3 times and show minimal value:
> 
> bzr --no-plugins --no-aliases st
> time: 1.032 sec.
> 
> bzr --no-plugins --no-aliases st -S
> time: 1.094 sec.
> 
> As you could see there is small difference in numbers but it's not bad.
> 
> With my eol changes (running from python sources):
> 
> python bzr --no-plugins --no-aliases st
> time: 1.656 sec.
> 
> python bzr --no-plugins --no-aliases st -S
> time: 5.828 sec.
> 
> This difference seems a bit TOO much. Something really wrong here.
> Can somebody give me a hint why it behaves *so* different?
> 
> One suspicious point about my eol code and its interaction with dirstate:
> for obtaining 'eol' versioned propertiy value I run for every entry
> method tree.id2path(fileid). I have suspicious that in the case
> of status --short inventory is not built, and every my lookup ends in
> building inventory in memory or something similar. Could be this is the 
> case?
> 
> Even if I rework my code to provide lazy lookup for 'eol' property this
> will not help for the case of many changes in the tree. Because anyway 
> for every
> potentially changed file I will end up with the same problem 
> (tree.id2path IMO).
> 
> Any suggestions is very appreciated.
> 
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: id2path.in.status.diff
Url: https://lists.ubuntu.com/archives/bazaar/attachments/20080411/0522474c/attachment.diff 


More information about the bazaar mailing list