/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: Vincent Ladeuil
  • Date: 2012-01-05 14:26:58 UTC
  • mto: This revision was merged to the branch mainline in revision 6468.
  • Revision ID: v.ladeuil+lp@free.fr-20120105142658-vek3v6pzlxb751s2
Tests passing for a first rough version of a cached branch config store. The changes here are too invasive and several parallel proposals have been made. 

@only_raises is evil and gave a hard time since any exception during
save_changes() was swallowed.

Possible improvements: 

- add some needs_write_lock decorators to crucial
  methods (_set_config_location ?) but keep locking the branch at higher levels

- decorate branch.unlock to call stack.save if last_lock() it True
  outside of @only_raises scope (evil decorator)

- add @needs_write_lock to stack.set and stack.remove (will probably get
  rid of most testing issues) we probably need a specialized decorator
  that can relay to the store and from there to the branch or whatever is
  needed. This will also helps bzr config to get it right. The
  get_mutable_section trick should not be needed anymore either.

- decorate branch.unlock to call stack.save if last_lock() it True outside
  of @only_raises scope (evil decorator)

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/performance-use-case-analysis.txt
38
38
be constant time. Retrieval of the annotated text should be roughly
39
39
constant for any text of the same size regardless of the number of
40
40
revisions contributing to its content. Mapping of the revision ids to
41
 
dotted revnos could be done as the text is retrieved, but its completely
 
41
dotted revnos could be done as the text is retrieved, but it's completely
42
42
fine to post-process the annotated text to obtain dotted-revnos.'
43
43
 
44
44
What factors should be considered?
79
79
- locality of reference: If an operation requires data that is located
80
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. It's
83
83
  fairly tricky to add locality of reference after the fact, so I think
84
84
  its worth considering up front.
85
85
 
102
102
file-level operation latency considerations.
103
103
 
104
104
Many performance problems only become visible when changing the scaling knobs
105
 
upwards to large trees. On small trees its our baseline performance that drives
106
 
incremental improvements; on large trees its the amount of processing per item
 
105
upwards to large trees. On small trees it's our baseline performance that drives
 
106
incremental improvements; on large trees it's the amount of processing per item
107
107
that drives performance. A significant goal therefore is to keep the amount of
108
108
data to be processed under control. Ideally we can scale in a sublinear fashion
109
109
for all operations, but we MUST NOT scale even linearly for operations that