bzr-explorer-dev team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gary van der Merwe wrote:
> On Tue, Sep 22, 2009 at 5:47 PM, John Arbash Meinel
> <john@xxxxxxxxxxxxxxxxx> wrote:
>> I'll just mention that I think there is a strong case for having a WT
>> widget that acts differently than a RevisionTree widget. Namely because
>> a RT cannot have any changes, or conflicts, or... Not to mention that
>> lookups in a WT are often best done by path, while lookups for a RT are
>> best done by file-id.
>>
>> Also, a WT widget should probably be populated by something like
>> 'iter_changes(include_unchanged=True, include_unknowns=True)', though
>> I'm not 100% sure how that handles ignored (you probably have to call
>> 'is_ignored()' yourself on any unknown files.)
> 
> qbzr's TreeWiget can show 3 different views:
> 
>  1. A RT view
>  2. A WT view that "merges" the data from the inventory, and iter_changes
>  3. A WT view that just shows changes (Used for qcommit, qadd, and qrevert)
> 
> I'm not to sure what the use cases for explorer will be, but I think
> you will be using the 2nd type.
> 
> The 1st and 2nd types load lazily. So at start up, we only read from
> the inventory, the children from root, and only when expand a
> directory when it is expanded by the user. I hope that this will
> provide good performance for large, deep trees (but I don't expect it
> to for large, flat trees.) It was in order to achieve this that I
> "merge" inventory data, and iter_changes data, rather than just
> calling iter_changes(include_unchanged=True, because it does not allow
> for me to randomly access a directory. It has to be read in the order
> that the iter provides.
> 
> The columns, and context menu items differ between views 1, and 2+3.

So probably the biggest problem with it, is that it is *another*
implementation of 'iter_changes' which means that you have to handle all
of the edge cases that we've already ironed out elsewhere. iter_changes
has also been performanced tuned quite a bit.

I do understand the goal of partial loading. Whether that could be
approached with something like a "recurse=False" flag on iter_changes,
or something else...

If the inodes are in cache, then recursively statting a 50k tree can be
done in a second, so it isn't a terrible overhead. Though cold cache
performance could be significantly different.

*I* would like to see us create an api in bzrlib that is similar to
iter_changes that gives you what you need. With the main caveat that it
should also be an object api, rather than a tuple one.

We thought we needed tuples because they were much faster to create. But
I think our profiling stats were a bit off. It is true that:
  python -m timeit "(1, 2)"
  0.0225 usec per loop

Is the fastest thing ever, but that is because the (1, 2) is statically
compiled, and there is no allocation being done. If you change it to:
  python -m timeit -s "x = [1, 2]" "tuple(x)"
  0.202 usec per loop

It slows down a bit. Such that my Key type:
  python -m timeit -s "x = [1, 2]" "Key(*x)"
  0.193 usec per loop

Is actually slightly faster. Using a real class is slower:
  0.515 usec per loop

But only 2:1, not the 20:1 we initially think from the inline test. Then
again, I think foo[0] is evaluated in the main loop, rather than needing
a getattr() overhead. So we may need to balance things appropriately.

  x._args
    0.0565 usec
  list[0]
    0.0363 usec
  tuple[0]
    0.0435 usec

(According to Spiv, list access is done completely in the main loop,
while tuples still use the tp_item interface.)


Anyway, I'm off on a tangent. Essentially, I'd like to see bzrlib
provide you with something you can use, rather than having another
iter_changes implementation to maintain...

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq5CeMACgkQJdeBCYSNAANC4ACgg9dxix5z1764OdGwdYSLWHss
FisAn2OMd0rbkbIss5RzNmz6sSbq/n3V
=JQSX
-----END PGP SIGNATURE-----