/brz/remove-bazaar : changes

» Changes from revision 3711.3.23

To get this branch, use:

bzr branch
http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

From Revision 3711.3.23 to 3711.3.4

expand all

Rev	Summary	Authors	Date
3711.3.23	Documentation and cleanup. Documentation and cleanup. Improve the docstring for _filter_revisions_touching_file_id to indicate what revisions will and won't be returned. Other general suggestions from Ian.	John Arbash Meinel	17 years ago
3711.3.22	Remove a hangover 'assert' Remove a hangover 'assert'	John Arbash Meinel	17 years ago
3711.3.21	Fix GraphIndex to properly generate _nodes_by_keys on demand... Fix GraphIndex to properly generate _nodes_by_keys on demand.	John Arbash Meinel	17 years ago
3711.3.20	merge bzr.dev and clean up NEWS merge bzr.dev and clean up NEWS	John Arbash Meinel	17 years ago
3711.3.19	Add a TODO discussing how our index requests should evolve. Add a TODO discussing how our index requests should evolve.	John Arbash Meinel	17 years ago
3711.3.18	Update NEWS based on the current algorithm. Update NEWS based on the current algorithm.	John Arbash Meinel	17 years ago
3711.3.17	Fix the 'test_log' tests Fix the 'test_log' tests	John Arbash Meinel	17 years ago
3711.3.16	Doc update. Doc update.	John Arbash Meinel	17 years ago
3711.3.15	Work around GraphIndex inefficiencies by requesting keys 100... Work around GraphIndex inefficiencies by requesting keys 1000 at a time.	John Arbash Meinel	17 years ago
3711.3.14	Change the per-file log algorithm dramatically. Change the per-file log algorithm dramatically. Now we use the merge_sort information to decide when to show another entry. It seems this changes what is actually logged. This is because sometimes a branch merges the trunk. And in that case, it will be bringing in the changes to a file, which the feature branch did not have before. However, for people using 'bzr log file' I believe those are uninteresting nodes. Memory consumption is good (240MB, mostly from text_index._buffer_all), speed is good (28s, also mostly in _buffer_all). Changing the code to request one key at a time saves the buffer all, but at the expense of lots of bisects. In some cases it is faster and saves memory (23s, 88MB), but on bzr.dev it is slower.	John Arbash Meinel	17 years ago
3711.3.13	Shave off another 5s by not building 'node_by_key' Shave off another 5s by not building 'node_by_key'	John Arbash Meinel	17 years ago
3711.3.12	Document the advantage of using a revision_id set, instead o... Document the advantage of using a revision_id set, instead of a (file_id, revision_id) one.	John Arbash Meinel	17 years ago
3711.3.11	Clean out the debugging code. Clean out the debugging code.	John Arbash Meinel	17 years ago
3711.3.10	Document some other alternatives, but in the end, just go wi... Document some other alternatives, but in the end, just go with the memory consuming fast 'frozenset()'	John Arbash Meinel	17 years ago
3711.3.9	Switch back to using a single dict. Switch back to using a single dict. The algorithm is simpler, and though I rember differently, the numbers show that it performs identically.	John Arbash Meinel	17 years ago
3711.3.8	It seems the specific layout of dicts doesn't matter. It seems the specific layout of dicts doesn't matter. Using 2 dicts, 1 dict and a list, 1 dict all had identical memory and CPU numbers. The only thing that matters is: a) We can't use mixed mode with a single dictionary, because it gets very confused and performs poorly. b) If you always use tuples, you cut memory from 410MB => 272MB, but performance jumps 42s => 50s c) 'mixed' mode is inbetween, with 400MB and 43s. However, it is pretty much just the 'frozenset' performance.	John Arbash Meinel	17 years ago
3711.3.7	Instead of using a dictionary for cached ancestries, Instead of using a dictionary for cached ancestries, use a list. This also lets us use integer offsets in our mapping, rather than revision ids.	John Arbash Meinel	17 years ago
3711.3.6	Changing back to using a single dict saves memory, Changing back to using a single dict saves memory, at the cost of CPU.	John Arbash Meinel	17 years ago
3711.3.5	a bit more debug info a bit more debug info	John Arbash Meinel	17 years ago
3711.3.4	Significantly faster, but consuming more memory. Significantly faster, but consuming more memory. We are back down to 42.6s, but we now consume 409MB. The current form keeps the value list separate from the revision pointers. That way we don't have to re-do the computation when we hit the same nodes repeatedly.	John Arbash Meinel	17 years ago

Older »