← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2007-06-25 09:23:03 UTC
  • mfrom: (2485.7.2 per-repository-test-setup)
  • Revision ID: pqm@pqm.ubuntu.com-20070625092303-yr8bqbke8snrmkig
(robertc) Relocate TestCaseWithRepository to be more central.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/planned-performance-changes.txt
43
43
   without changing disk, possibly with a performance hit until the disk
44
44
   formats match the validatory logic. It will be hard to tell if we have the
45
45
   right routine for that until all the disk changes are complete, so while
46
 
   this is a library only change, it's likely one that will be delayed to near
 
46
   this is a library only change, its likely one that will be delayed to near
47
47
   the end of the process.
48
48
 
49
49
 * Add an explicit API for managing cached annotations. While annotations are
50
50
   considered a cache this is not exposed in such a way that cache operations
51
51
   like 'drop the cache' can be performed. On current disk formats the cache is
52
52
   mandatory, but an API to manage would allow refreshing of the cache (e.g.
53
 
   after ghosts are filled in during baz conversions).
 
53
   after ghosts are filled in in baz conversions).
54
54
 
55
55
 * Use the _iter_changes API to perform merges. This is a small change that may
56
56
   remove the need to use inventories in merge, making a dramatic difference to
68
68
   through review.
69
69
 
70
70
 * Stop requiring full memory copies of files. Currently bzr requires that it
71
 
   can hold 3 copies of any file it's versioning in memory. Solving this is
 
71
   can hold 3 copies of any file its versioning in memory. Solving this is
72
72
   tricky, particularly without performance regressions on small files, but
73
73
   without solving it versioning of .iso and other large objects will continue
74
74
   to be extremely painful.
84
84
 * Revision data manipulation API. We need a single streaming API for adding
85
85
   data to or getting it from a repository. This will need to allow hints such
86
86
   as 'optimise for size', or 'optimise for fast-addition' to meet the various
87
 
   users planned, but it is a core part of the library today, and it's not
 
87
   users planned, but it is a core part of the library today, and its not
88
88
   sufficiently clean to let us simplify/remove a lot of related code today.
89
89
 
90
90
Interoperable disk changes
93
93
 * New container format to allow single-file description of multiple named
94
94
   objects. This will provide the basis for transmission of revisions over the
95
95
   network, the new bundle format, and possibly a new repository format as
96
 
   well. [Core implemented]
 
96
   well. [Core implemented] 
97
97
 
98
98
 * Separate the annotation cache from the storage of actual file texts and make
99
99
   the annotation style, and when to do it, configurable. This will reduce data
104
104
 
105
105
 * Repository disk operation ordering. The order that tasks access data within
106
106
   the repository and the layout of the data should be harmonised. This will
107
 
   require disk format changes but does not inherently alter the model, so it's
 
107
   require disk format changes but does not inherently alter the model, so its
108
108
   straight forward to export from a repository that has been optimised in this
109
109
   way to a 0.16 based repository.
110
110
 
120
120
   between two historical trees much more efficiently than the current
121
121
   repositories.
122
122
 
 
123
 * Delta storage optimisation. We plan to change the delta storage logic to use
 
124
   a binary delta like xdelta rather than using line based deltas from python.
 
125
   These binary deltas could be done along ancestry ordering, or other
 
126
   arbitrary patterns chosen for their intended use. Line based deltas will
 
127
   still be created for cached annotations. This is still under some discussion.
 
128
   http://bazaar-vcs.org/PerformanceRoadmap/Xdelta
 
129
 
123
130
 * Greatest distance from origin cache. This is a possible change to introduce,
124
131
   but it may be unnecessary - listed here for completeness till it has been
125
132
   established as [un]needed.