[MERGE] bzrlib.osutils fixes

[Andrew Bennetts]

John Arbash Meinel wrote:
[...]
> >> will kill us. But it is another function call and hash lookup in a
> >> critical loop.
> > 
> > Huh? in the top of dirstate.py, we can do
> > _mini_kind_to_kind = {'k':path_info.kind_directory,
> >  't':path_info.kind_tree,
> >  ...}
> > 
> > And then use that as we were. I dont see why there is a function call
> > involved.
> 
> That *is* the function call. (The dict lookup). But as I said, it
> probably isn't terrible. I would just like us to specifically measure
> it, rather than guessing.

Dict lookups are much faster than pure python function calls, even for a
function that does nothing:

$ python -m timeit -s "d = dict((x, x) for x in 'abcdefgh')" "d['a']"
10000000 loops, best of 3: 0.171 usec per loop
$ python -m timeit -s "def f(): pass" "f()"
1000000 loops, best of 3: 0.325 usec per loop

(Calls to C functions are almost as fast, but operators like __getitem__ get a
slight advantage because the interpreter knows exactly what the signatures are:

$ python -m timeit -s "from operator import neg" "neg(0)"
1000000 loops, best of 3: 0.182 usec per loop
)

So it's a bit misleading to refer to dict lookups as function calls in
performance terms.

[...]
> 
> One thing that I recall from David's work, is that by switching to
> pyrex, you can call PyDict_GetItem (or whatever), rather than
> PyObject_GetItem. Which is supposed to make a rather large difference.
> 
> And for the record, this *is* quite a bit easier than what I've seen
> done for other wrappers. (Raw C extensions, or Boost::Python). Which is
> as I would have hoped.

Yeah, pyrex is quite nice.

-Andrew.