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

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

Rev	Summary	Authors	Date
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	16 years ago
3711.3.20	merge bzr.dev and clean up NEWS merge bzr.dev and clean up NEWS	John Arbash Meinel	16 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	16 years ago
3711.3.18	Update NEWS based on the current algorithm. Update NEWS based on the current algorithm.	John Arbash Meinel	16 years ago
3711.3.17	Fix the 'test_log' tests Fix the 'test_log' tests	John Arbash Meinel	16 years ago
3711.3.16	Doc update. Doc update.	John Arbash Meinel	16 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	16 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	16 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	16 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	16 years ago
3711.3.11	Clean out the debugging code. Clean out the debugging code.	John Arbash Meinel	16 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	16 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	16 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	16 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	16 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	16 years ago
3711.3.5	a bit more debug info a bit more debug info	John Arbash Meinel	16 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	16 years ago
3711.3.3	A bit of a Frankenstein now, but it drops memory dramaticall... A bit of a Frankenstein now, but it drops memory dramatically. Now we build up new nodes into a list, and cache them as tuples. If we end up computing the frozenset() for a node, we then cache it as such. Memory consumption is now only 101MB, though processing time is 53s.	John Arbash Meinel	16 years ago
3711.3.2	Trade off time versus memory consumption. Trade off time versus memory consumption. [frozen]set() objects always waste a bit of memory, in order to avoid hash collisions. So if we cache the ancestry by using tuples instead of sets, we can save a bit of memory. For mysql, this is 272MB versus 380MB. However, it costs CPU time to regenerate all of these sets 56.7s versus 44.2s.	John Arbash Meinel	16 years ago

Older »