[RFC] question about different behavior of WorkingTree.iter_changes
bialix at ukr.net
Fri Apr 11 12:54:39 BST 2008
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.
More information about the bazaar