ideas for C optimization wanted

[John Arbash Meinel]

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

David Ingamells wrote:
| Reminds me of the time when I used to code in Fortran and stepped down
| to assembler to speed-up the critical bits! I also remember that
| choosing the right small bits of code to rewrite in assembler gave very
| significant speed-ups.
|
| One word of caution: by adding some compiled code to bzr you are
| doubling (actually more) the complexity of the build and release of the
| code. Presently I can just run core bzr "out-of-the-box" from the dev
| branch, but if bits are in C that won't be possible any more. I strongly
| recommend that you take some time to get the build side of things sorted
| before you go too far down the C path. A bit of effort in that area now
| will save lots of grief later.
|
| good luck!

Actually, we already have some bits written in pyrex and C (pyrex is
python-like but can be generated into C code to be compiled.)

While you *can* run straight from a tree, running "make" will build the
extensions and speed up a few common actions.

For tarball releases, we process the pyrex => C, so people don't need
the pyrex compiler for released code. (Sort of like including
Makefile.am => Makefile.in so people don't need automake.)

So I'm pretty sure we already have the build process worked out. To
date, we've always had python fallback code, which is almost definitely
something we would try to maintain. So you *can* run with 0 setup, but
with a bit of setup things will work even better.

John
=:->


|
| Martin Pool wrote:
|> Tim said to me he was interested in doing some C or Pyrex code to
|> speed up Bazaar, and asked for suggestions on where to begin.
|>
|> One that comes to mind for me would be changing some of the larger
|> performance-critical functions in workingtree_4.py (like
|> InterDirStateTree.iter_changes) to have a simple Python implementation
|> and a fast C implementation.  Some of them are pretty long, partly
|> because of wanting to avoid python function-call overhead.   But it
|> would be a good idea to do some profiling with lsprof first and see if
|> they are actually near the top in current code.  You should make sure
|> lsprof is installed and working before going offline.
|>
|> There are some notes here
|> <http://doc.bazaar-vcs.org/bzr.dev/developers/profiling.html> on how
|> to profile Bazaar and in
|> <http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/HACKING.html> on
|> development generally, including writing C extensions.
|>
|> Another thing that would be good but might be beyond the time
|> available would be to bind in xdelta or another binary format into a
|> new repository format.
|>
|>
|
|
|

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

iEYEARECAAYFAkhs4eQACgkQJdeBCYSNAANikgCgk/8u5LWiaL4xRlDaKm32V7Md
bwgAn3aB4Yb/JSN23oqXuhDuRxsR76QR
=yLMv
-----END PGP SIGNATURE-----