[RFC][PERFORMANCE][PYREX][TIRED OF THESE YET?] *fast* walkdirs.

[John Arbash Meinel]

Andrew Bennetts wrote:
> On Thu, Jun 15, 2006 at 08:35:19AM -0500, John Arbash Meinel wrote:

...

> I agree; I don't see any reason not to include them in the core.  Do we really
> want to distribute the C implementations seperately?  Why is this any different
> to any pure python code -- e.g. we don't ship the diff logic in a plugin (pure
> python or not) so that we can upgrade it to a newer, more optimised version
> seperately.  The extra complexity and risk of version skew isn't worth the
> slight extra flexibility.

Actually, with python we can always ship a new optimized one as a
plugin, and then it can monkeypatch itself in where it is needed. We
don't have to ship it from the beginning as a plugin that can be replaced.

If you want some examples, I have:
http://bzr.arbash-meinel.com/plugins/

Which has 'bzr_extensions' which monkey patches the XML writer with a
C++ version, as well as the RIO writer/reader, and the PatienceDiff
algorithm.

I also have 'shortlog' which monkey patches in to change the default log
options (I've had it a lot longer than ALIASES).

Or 'dns_cache' which considers monkey patching urllib since it doesn't
cache host addresses, and causes us to require another round trip to the
DNS server for every request from the remote.

Or 'gpg_uses_tempfile' which is a personal hack since my gpg agent can't
prompt me if you pipe into gpg.

At least my plugins have a long history of monkey patching the bzr
codebase. I tend to do it for anything experimental or controversial. Or
anything that I want to get going on, and may take a while for bzr.dev
to incorporate.

> 
>> At this point I'm on the fence. I've done all my work in plugins that
>> load themselves and monkeypatch the appropriate functions. I can turn
>> them on/off with 'bzr --no-plugins'. However, if we feel that these are
>> key performance improvements, then probably they shouldn't be disabled
>> by that flag.
> 
> Right.  A --debug-disable-C flag or something might theoretically be useful, but
> is clearly a different use case than for --no-plugins.
> 
> -Andrew.

Yeah. I agree with you on version skew. I also agree that Robert's
method is a little too 'magical'. And doesn't give you any way to
disable it. I'm not sure if he does it for expediency as he does
prototyping, or if it is his long-term plan.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060615/ae9eaa7b/attachment.pgp