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

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

Rev	Summary	Authors	Date
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
4454.3.45	A bit of tweaking to the _update_from_other_parents drops us... A bit of tweaking to the _update_from_other_parents drops us to 7.67s	John Arbash Meinel	15 years ago
4454.3.44	Initial results show no improvement for pyrexifing _update_f... Initial results show no improvement for pyrexifing _update_from_one_parent. I'm a bit surprised, but apparently PyList_GetSlice is pretty efficient.	John Arbash Meinel	15 years ago
4454.3.43	Initial implementation of a Pyrex annotator. Initial implementation of a Pyrex annotator. Drops the time down to 8.6s down from 9.7s. This implementation is basically just a copy of the python one, so I'm a bit surprised to see that much of a win already.	John Arbash Meinel	15 years ago
4454.3.42	Make use of the passed in progress bar. Make use of the passed in progress bar.	John Arbash Meinel	15 years ago
4454.3.41	Cache the heads provider as long as we know that the parent_... Cache the heads provider as long as we know that the parent_map hasn't changed.	John Arbash Meinel	15 years ago
4454.3.40	Shave a bit more time off by using subset matching to skip w... Shave a bit more time off by using subset matching to skip whole regions. Drops us down to 9.2s, slightly faster than bzr.dev, and no pyrex yet.	John Arbash Meinel	15 years ago
4454.3.39	Merge bzr.dev 4474 to get the latest _KnownGraph code. Merge bzr.dev 4474 to get the latest _KnownGraph code.	John Arbash Meinel	15 years ago
4454.3.38	Start using left-matching-blocks during the actual annotatio... Start using left-matching-blocks during the actual annotation. Down to 11.3s.	John Arbash Meinel	15 years ago
4454.3.37	Add tests tha left-matching-blocks gets populated. Add tests tha left-matching-blocks gets populated.	John Arbash Meinel	15 years ago
4454.3.36	Only cache the content objects that we will reuse. Only cache the content objects that we will reuse. Peak memory is down to 92MB, and annotate time down to 15.9s	John Arbash Meinel	15 years ago
4454.3.35	Figure out why we don't want to copy_base_content=False. Figure out why we don't want to copy_base_content=False.	John Arbash Meinel	15 years ago
4454.3.34	Removing compression_parent Content objs drops us from 238MB... Removing compression_parent Content objs drops us from 238MB down to 146MB. Setting copy_base_content = False seems to cause errors ATM :(. So we need to dig deeper.	John Arbash Meinel	15 years ago
4454.3.33	Change the _expand_record code to pop out old content object... Change the _expand_record code to pop out old content objects. Also, re-use the base parent content object when possible.	John Arbash Meinel	15 years ago
4454.3.32	using this custom extraction code drops us from 30.5s => 17.... using this custom extraction code drops us from 30.5s => 17.6s for annotate NEWS. It would seem that there are some severe inefficiencies for get_record_stream('topological', True)	John Arbash Meinel	15 years ago
4454.3.31	Change the processing lines to now handle fallbacks properly... Change the processing lines to now handle fallbacks properly.	John Arbash Meinel	15 years ago
4454.3.30	add a bit more work to be able to process 'pending_annotatio... add a bit more work to be able to process 'pending_annotations'.	John Arbash Meinel	15 years ago
4454.3.29	Some code comments about what needs to happen. Some code comments about what needs to happen. It also makes it a bit more obvious why the code is hard to wrap your head around. In essense there are 2 queues. Also, we want to intermingle the steps so that the caches can be depopulated as we get the deltas we need, etc.	John Arbash Meinel	15 years ago
4454.3.28	Continue breaking things to build it up cleanly. Continue breaking things to build it up cleanly. At this point we have an _expand_record which is used to turn record streams into text lines. Eventually it will do things like track 'num_compression_children' so that it can re-use content objects, etc. The code already handles removing 'text' entries as part of Annotator. At the moment, nodes get queued up, but we haven't worked out when/how to pull them back out of the queue.	John Arbash Meinel	15 years ago

Older »