← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/performance-use-case-analysis.txt

  • Committer: Marius Kruger
  • Date: 2007-06-27 18:48:10 UTC
  • mfrom: (2557 +trunk)
  • mto: (2605.1.1 rm-renamed)
  • mto: This revision was merged to the branch mainline in revision 2609.
  • Revision ID: marius.kruger@enerweb.co.za-20070627184810-4jq1y5f20xafow9w
Merge with bzr.dev

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/performance-use-case-analysis.txt
 
1
.. This document describes _how_ to do use case analyses and what we want
 
2
.. to get out of them; for the specific cases see the files referenced by
 
3
.. performance-roadmap.txt 
 
4
 
1
5
Analysing a specific use case
2
6
=============================
3
7
 
49
53
   - The time to get bzr ready to begin the use case.
50
54
 
51
55
- scaling: how does performance change when any of the follow aspects
52
 
  of the system are ratched massively up or down:
 
56
  of the system are ratcheted massively up or down:
53
57
 
54
58
   - number of files/dirs/symlinks/subtrees in a tree (both working and 
55
59
     revision trees)
100
104
Many performance problems only become visible when changing the scaling knobs
101
105
upwards to large trees. On small trees its our baseline performance that drives
102
106
incremental improvements; on large trees its the amount of processing per item
103
 
that drives performance. A significant goal therefore is to keep the amouont of
 
107
that drives performance. A significant goal therefore is to keep the amount of
104
108
data to be processed under control. Ideally we can scale in a sublinear fashion
105
109
for all operations, but we MUST NOT scale even linearly for operations that
106
110
invoke a latency multiplier. For example, reading a file on disk requires