/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

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

  • Committer: John Arbash Meinel
  • Date: 2009-06-17 19:08:25 UTC
  • mto: This revision was merged to the branch mainline in revision 4460.
  • Revision ID: john@arbash-meinel.com-20090617190825-ktfk82li57rf2im6
It seems that fetch() no longer returns the number of revisions fetched.
It still does for *some* InterRepository fetch paths, but the generic one does not.
It is also not easy to get it to, since the Source and Sink are the ones
that would know how many keys were transmitted, and they are potentially 'remote'
objects.

This was also only tested to occur as a by-product in a random 'test_commit' test.
I assume if we really wanted the assurance, we would have a per_repo or interrepo
test for it.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/performance-use-case-analysis.txt
1
1
.. This document describes _how_ to do use case analyses and what we want
2
2
.. to get out of them; for the specific cases see the files referenced by
3
 
.. performance-roadmap.txt
 
3
.. performance-roadmap.txt 
4
4
 
5
5
Analysing a specific use case
6
6
=============================
55
55
- scaling: how does performance change when any of the follow aspects
56
56
  of the system are ratcheted massively up or down:
57
57
 
58
 
   - number of files/dirs/symlinks/subtrees in a tree (both working and
 
58
   - number of files/dirs/symlinks/subtrees in a tree (both working and 
59
59
     revision trees)
60
60
   - size of any particular file
61
61
   - number of elements within a single directory
77
77
   - bandwidth when performing semantic operations.
78
78
 
79
79
- locality of reference: If an operation requires data that is located
80
 
  within a small region at any point, we often get better performance
 
80
  within a small region at any point, we often get better performance 
81
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
 
82
  same amount of data but with a lower locality of reference. Its 
83
83
  fairly tricky to add locality of reference after the fact, so I think
84
84
  its worth considering up front.
85
85
 
89
89
measurements, in an ideal world there would be no more than one round
90
90
trip for each semantic operation. What there must not be is one round
91
91
trip per revision involved in the revisionid->dotted number mapping, nor
92
 
per each revision id attributed to a line in the text.
 
92
per each revision id attributed to a line in the text. 
93
93
 
94
94
Not all the items mentioned above are created equal. The analysis should
95
95
include the parameters considered and the common case values for each - the