← 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: Canonical.com Patch Queue Manager
  • Date: 2007-07-22 18:09:04 UTC
  • mfrom: (2485.8.63 bzr.connection.sharing)
  • Revision ID: pqm@pqm.ubuntu.com-20070722180904-wy7y7oyi32wbghgf
Transport connection sharing

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
 
4
8
The analysis of a use case needs to provide as outputs:
5
9
 * The functional requirements that the use case has to satisfy.
15
19
   should also be mentioned.
16
20
 
17
21
Performing the analysis
18
 
-----------------------
 
22
=======================
19
23
 
20
24
The analysis needs to be able to define the characteristics of the
21
25
involved disk storage and APIs. That means we need to examine the data
38
42
fine to post-process the annotated text to obtain dotted-revnos.'
39
43
 
40
44
What factors should be considered?
41
 
----------------------------------
 
45
==================================
42
46
 
43
47
Obviously, those that will make for an extremely fast system :). There
44
48
are many possible factors, but the ones I think are most interesting to
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)
71
75
   - bandwidth to the disk storage
72
76
   - latency to perform semantic operations (hpss specific)
73
77
   - bandwidth when performing semantic operations.
 
78
 
74
79
- locality of reference: If an operation requires data that is located
75
 
   within a small region at any point, we often get better performance 
76
 
   than with an implementation of the same operation that requires the
77
 
   same amount of data but with a lower locality of reference. Its 
78
 
   fairly tricky to add locality of reference after the fact, so I think
79
 
   its worth considering up front.
 
80
  within a small region at any point, we often get better performance 
 
81
  than with an implementation of the same operation that requires the
 
82
  same amount of data but with a lower locality of reference. Its 
 
83
  fairly tricky to add locality of reference after the fact, so I think
 
84
  its worth considering up front.
80
85
 
81
86
Using these factors, to the annotate example we can add that its
82
87
reasonable to do two 'semantic' round trips to the local tree, one to
99
104
Many performance problems only become visible when changing the scaling knobs
100
105
upwards to large trees. On small trees its our baseline performance that drives
101
106
incremental improvements; on large trees its the amount of processing per item
102
 
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
103
108
data to be processed under control. Ideally we can scale in a sublinear fashion
104
109
for all operations, but we MUST NOT scale even linearly for operations that
105
110
invoke a latency multiplier. For example, reading a file on disk requires