← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/performance-contributing.txt

  • Committer: John Arbash Meinel
  • Date: 2007-11-13 20:37:09 UTC
  • mto: This revision was merged to the branch mainline in revision 3001.
  • Revision ID: john@arbash-meinel.com-20071113203709-kysdte0emqv84pnj
https://launchpad.net/bugs/162486
Fix bug #162486, by having RemoteBranch properly initialize self._revision_id_to_revno_map.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/performance-contributing.txt
 
1
Contributing to the performance drive
 
2
=====================================
 
3
 
 
4
.. contents:: :local:
 
5
 
 
6
What needs doing?
 
7
-----------------
 
8
 
 
9
There is plenty of code to write. Testers are always welcome for experimental
 
10
changes. In general, pick a BLUE node from performance.png which has nothing
 
11
pointing at it that is also BLUE, and start working on that.
 
12
 
 
13
Adhoc performance work can also be done. One useful tool is the 'evil' debug
 
14
flag. For instance running ``bzr -Devil commit -m 'test'`` will log a backtrace
 
15
to the bzr log file for every method call which triggers a slow or non-scalable
 
16
part of the bzr library. So checking that a given command with ``-Devil`` has
 
17
no backtraces logged to the log file is a good way to find problem function
 
18
calls that might be nested deep in the code base.
 
19
 
 
20
Status
 
21
------
 
22
 
 
23
The performance drive is well under way. At the moment we are finalising the
 
24
analysis documents from the sprint at London. If you were not at that sprint,
 
25
please read the analysis documents - consider them living documents much like
 
26
code, to be patched and corrected.
 
27
 
 
28
If you were at the London performance sprint, please help finish documenting
 
29
the core command analysis work. The core commands that have not been analysed
 
30
are listed in performance.dot as the BLUE nodes. For quick reference:
 
31
 
 
32
* status
 
33
* log
 
34
* diff
 
35
* uncommit
 
36
* missing
 
37
* update
 
38
* cbranch
 
39
 
 
40
Once a given command has had its analysis created, the bottleneck of 'folk who
 
41
attended London' is removed. The next task is in general the creation of a
 
42
targeted API stack for that command. This API stack is done by starting with
 
43
the cmd object in ``builtins.py`` and cleaning up the code so that the API used
 
44
there is one which allows an implementation matching the analysis document.
 
45
This then gets repeated, iteratively, on each of the called API's, until all
 
46
the current slow code is cleanly abstracted behind the ``Tree``, ``Branch`` and
 
47
``Repository`` API's.
 
48
 
 
49
Resources
 
50
---------
 
51
 
 
52
The usual resources for contributing to bzr - the mailing list, wiki, bug
 
53
tracker and IRC channels are documented in the HACKING_ document. Additionally
 
54
there are members of the project focusing on performance at the moment who are
 
55
willing to mentor contributors on performance issues. Just send a mail to the
 
56
list asking for mentoring on the step of the performance plan you want to help
 
57
with.
 
58
 
 
59
.. _HACKING: HACKING.htm