~bzr-pqm/bzr/bzr.dev : changes

~bzr-pqm/bzr/bzr.dev » Changes from revision 4454.3.65

Rev	Summary	Authors	Date
4454.3.65	Tests that VF implementations support .get_annotator() Tests that VF implementations support .get_annotator() This also meant supporting no-graph style VF implementations, which wasn't too bad.	John Arbash Meinel	15 years ago
4454.3.64	Ensure that _KnitAnnotator also supports add_special_text. Ensure that _KnitAnnotator also supports add_special_text. It already had some support for handling texts that were already present.	John Arbash Meinel	15 years ago
4454.3.63	Copy the implementation over to the Pyrex version. Copy the implementation over to the Pyrex version.	John Arbash Meinel	15 years ago
4454.3.62	Add a test that shows when parent texts, etc, are present, w... Add a test that shows when parent texts, etc, are present, we don't request again.	John Arbash Meinel	15 years ago
4454.3.61	Start implementing an Annotator.add_special_text functionali... Start implementing an Annotator.add_special_text functionality. The Python implementation supports it. Basically, it is meant to allow things like WT and PreviewTree to insert the 'current' content into the graph, so that we can get local modifications into the annotations. There is also some work here to get support for texts that are already cached in the annotator. So that we avoid extracting them, and can shortcut the history.	John Arbash Meinel	15 years ago
4454.3.60	Update copyright Update copyright	John Arbash Meinel	15 years ago
4454.3.59	Track down why the annotate retry code was failing. Track down why the annotate retry code was failing. It was just that we were re-using a variable name, which was causing us to retry and annotate the wrong text.	John Arbash Meinel	15 years ago
4454.3.58	Enable the new annotator for gc format repos. Enable the new annotator for gc format repos. Determine that I was accidentally calling _get_needed_keys 2 times, which was causing the code to double the reference counts, and thus never free the desired items.	John Arbash Meinel	15 years ago
4454.3.57	Merge bzr.dev 4504 Merge bzr.dev 4504	John Arbash Meinel	15 years ago
4454.3.56	Cleanup pass, remove all of the debugging counters. Cleanup pass, remove all of the debugging counters.	John Arbash Meinel	15 years ago
4454.3.55	Remove some debugging counters. Remove some debugging counters. Current 'annotate' breakdown: NEWS builtins.py 6.564 2.265 overall time 0.164 0.038 resolve heads() etc on annotated lines 2.103 0.841 extract texts, convert delta to left-matching-block 4.289 1.382 compute annotations 3.533 1.101 get_matching_blocks() (left and right parents) 0.704 0.180 update left-hand parent annotations (includes above) 3.251 1.068 update right-hand parents 0.118 0.030 resolve annotation lines So by percentage, 54% of the time is in PatienceSequenceMatcher, 32% of the time is extracting texts, and only 14% of the time is in the annotation work.	John Arbash Meinel	15 years ago
4454.3.54	Access the list object directly, and copy the pointers. Access the list object directly, and copy the pointers. Drops the time for left-parent resolution from 260ms down to 120ms.	John Arbash Meinel	15 years ago
4454.3.53	Minor tweak to make _update_counter cheaper. Minor tweak to make _update_counter cheaper.	John Arbash Meinel	15 years ago
4454.3.52	Tune the inner resolution loop a bit. Down to 125ms from 200... Tune the inner resolution loop a bit. Down to 125ms from 200+ms.	John Arbash Meinel	15 years ago
4454.3.51	Using a global cache gives us key uniqueness. Using a global cache gives us key uniqueness. Using the global cache gives 33k hits out of 36k checks. Using a local is about 20k hits. (Unsorted global is 30k hits.)	John Arbash Meinel	15 years ago
4454.3.50	Some internal cleanup, a few more counters. Some internal cleanup, a few more counters.	John Arbash Meinel	15 years ago
4454.3.49	More debugging. It seems NEWS and builtins are about 1.5 chi... More debugging. It seems NEWS and builtins are about 1.5 children on average.	John Arbash Meinel	15 years ago
4454.3.48	More debug timing. More debug timing. {'_process_pending': 0.31604861791095284, '_read_records_iter': 1.493346989631362, 'annotate one': 5.0270826320105231, 'annotate time': 7.4366645760843912, 'expand_record': 0.4893973954790547, 'first ann': 8498, 'get build graph': 0.24679763768858889, 'get_matching_blocks()': 3.7303522514733056, 'heads time': 0.1828461438535145, 'known blocks': 4389, 'left parents': 4560, 'multi heads': 30, 'multi source': 8649, 'one head': 8619, 'one source': 973, 'overall': 7.6605459632439326, 'resolve annotations': 0.2150744019142099, 'right parents': 2094, 'unknown blocks': 2265, 'update left': 0.9340078138422363, 'update other match': 3.3286844417377002, 'update other resolve': 0.34835153629861293, 'update rest': 3.7008640064589233} proc_pending + expand + read_raw gives about 2s to get the texts. and then we spend 5s annotating, 3.5s of that is get_matching_blocks(). So there is about 400ms left to trim out of _update_from_other_parents, which really isn't much. The next biggest time would be to improve the PatienceSequence information.	John Arbash Meinel	15 years ago
4454.3.47	lots of debugging timers. lots of debugging timers. For NEWS: {'annotate one': 4.9377005317715019, 'annotate time': 7.3725829679470429, 'first ann': 8498, 'heads time': 0.18344133123069994, 'multi heads': 30, 'multi source': 8649, 'one head': 8619, 'one source': 973, 'overall': 7.5956810851658521, 'resolve annotations': 0.21483317013754544, 'update left': 0.92649561606294317, 'update other match': 3.278116911506904, 'update other resolve': 0.32999194031643531, 'update rest': 3.6284887464747229} Looks like we spend 2 seconds extracting texts, 5 seconds annotating them. And of tht we spend 3.2s matching the right parent lines to the current text. We spend a fairly short amount of time resolving annotations, almost all of them resolve to a single head, which is also interesting.	John Arbash Meinel	15 years ago
4454.3.46	Combine left and right knowing that we already have sorted t... Combine left and right knowing that we already have sorted tuples. Add a cache of entries. Now down to 7.46s.	John Arbash Meinel	15 years ago

Older »