[RFC] question about different behavior of WorkingTree.iter_changes

[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.