← 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

(jameinel) Allow 'bzr serve' to interpret SIGHUP as a graceful shutdown.
 (bug #795025) (John A Meinel)

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, its likely one that will be delayed to near
 
46
   this is a library only change, it's 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 in baz conversions).
 
53
   after ghosts are filled in during 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 its versioning in memory. Solving this is
 
71
   can hold 3 copies of any file it's 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 its not
 
87
   users planned, but it is a core part of the library today, and it's 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 its
 
107
   require disk format changes but does not inherently alter the model, so it's
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
 
 
130
123
 * Greatest distance from origin cache. This is a possible change to introduce,
131
124
   but it may be unnecessary - listed here for completeness till it has been
132
125
   established as [un]needed.