← 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: John Arbash Meinel
  • Date: 2010-09-29 20:56:18 UTC
  • mto: This revision was merged to the branch mainline in revision 5452.
  • Revision ID: john@arbash-meinel.com-20100929205618-qlldxw4ykwt5511n
Move the new NEWS entry to the appropriate section.

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
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
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