/brz/remove-bazaar : changes

» Changes from revision 4593.5.30

To get this branch, use:

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

From Revision 4593.5.30 to 4593.5.11

expand all

Rev	Summary	Authors	Date
4593.5.30	Move the topo_sort implementation into KnownGraph, rather th... Move the topo_sort implementation into KnownGraph, rather than calling back to it.	John Arbash Meinel	16 years ago
4593.5.29	Remove the gc enable/disable code. Remove the gc enable/disable code. It doesn't seem to have a specific benefit in real world testing. Though a global gc.disable speeds up bzr log bzr.dev from 1.1s to 0.9s.	John Arbash Meinel	16 years ago
4593.5.28	Cleanup pass Cleanup pass	John Arbash Meinel	16 years ago
4593.5.27	bit of cleanup passes bit of cleanup passes	John Arbash Meinel	16 years ago
4593.5.26	small cleanup, a bit of comment tweaking. small cleanup, a bit of comment tweaking.	John Arbash Meinel	16 years ago
4593.5.25	Add tests that we detect GraphCycleError Add tests that we detect GraphCycleError Turned out to be quite important, because otherwise KnownGraph.merge_sort() ends up in an infinite loop w/ a GraphCycle. (unlike topo_sort which pretty much just ignores those nodes.)	John Arbash Meinel	16 years ago
4593.5.24	Switch some variables from Py_ssize_t to long Switch some variables from Py_ssize_t to long It turns out that long => PyInt is slightly faster than Py_ssize_t => PyInt because interally PyInt holds a 'long' and in theory Py_ssize_t could be bigger than a long. For what we were doing, we never needed anything bigger than 'long'.	John Arbash Meinel	16 years ago
4593.5.23	Move the end-of-merge computation into _pop_node Move the end-of-merge computation into _pop_node This makes the final loop to pass the nodes out in reverse topological order a fairly trivial step.	John Arbash Meinel	16 years ago
4593.5.22	Conform to the direct merge_sort test. Conform to the direct merge_sort test.	John Arbash Meinel	16 years ago
4593.5.21	Bring in the changes to merge_sort. Bring in the changes to merge_sort.	John Arbash Meinel	16 years ago
4593.5.20	Expose KnownGraph off of VersionedFiles Expose KnownGraph off of VersionedFiles handle ghosts (needs tests, doesn't seem to effect performance) list(tuple[1:]) is a couple ms slower than using my own loop. Net effect is: time bzr log -n0 -r -10..-1 real 0m2.559s time wbzr log -n0 -r -10..-1 real 0m1.170s time bzr log -n1 -r -10..-1 real 0m0.453s So the overhead for the extra graph is down from 2.1s to 0.7s	John Arbash Meinel	16 years ago
4593.5.19	Switch from having a MergeSortNode => KnownGraphNode to Switch from having a MergeSortNode => KnownGraphNode to having KnownGraphNode.extra => MergeSortNode This avoids some of the dict lookups, etc, especially while creating the nodes. I'm not 100% sure I like the layering, though. I suppose it could be considered a 'void*' for processing algorithms to use, similar to the \.seen member. # 92ms graph.KnownGraph().merge_sort() # 42ms kg.merge_sort()	John Arbash Meinel	16 years ago
4593.5.18	Note how much time we spend to reverse the sorted-nodes list Note how much time we spend to reverse the sorted-nodes list and create the final tuple representation. A good guess is that the bulk of the rest of the time is spent in actually allocating the new MergeNode objects.	John Arbash Meinel	16 years ago
4593.5.17	No need to pop one item off the stack after another. No need to pop one item off the stack after another. We can just iterate over the group and append to the output. Use direct function calls, rather than ordered.append. Down to: # 103ms graph.KnownGraph().merge_sort() # 55ms kg.merge_sort()	John Arbash Meinel	16 years ago
4593.5.16	Change the revno handling code. Change the revno handling code. # 112ms graph.KnownGraph().merge_sort() # 64ms kg.merge_sort()	John Arbash Meinel	16 years ago
4593.5.15	Use the same implementation of stack handling to avoid appen... Use the same implementation of stack handling to avoid append/pop. Instead we track what the 'current' entry is, and then grow the stack only when we need more space. This also turns into using direct list access, rather than python apis. Drops the time down: - # 138ms graph.KnownGraph().merge_sort() - # 89ms kg.merge_sort() + # 127ms graph.KnownGraph().merge_sort() + # 77ms kg.merge_sort()	John Arbash Meinel	16 years ago
4593.5.14	Merge bzr.dev 4615 Merge bzr.dev 4615 Bring in the latest faster-iter-ancestry.	John Arbash Meinel	16 years ago
4593.5.13	Moving into attributes instead of dicts improves performance... Moving into attributes instead of dicts improves performance: - # 194ms graph.KnownGraph().merge_sort() - # 143ms kg.merge_sort() + # 138ms graph.KnownGraph().merge_sort() + # 89ms kg.merge_sort() Probably the biggest win is that we can walk directly to the _MergeSortNode parent, without having to do dict lookups.	John Arbash Meinel	16 years ago
4593.5.12	Move some sets/dicts into attributes. Move some sets/dicts into attributes. This does expose an open question about 'merge_sort_race'.	John Arbash Meinel	16 years ago
4593.5.11	Without doing any real tuning yet, we see a decent speedup f... Without doing any real tuning yet, we see a decent speedup for merge_sort: Current performance numbers for merge_sort(bzr_dev_parent_map): 310ms tsort.merge_sort() 194ms graph.KnownGraph().merge_sort() 143ms kg.merge_sort()	John Arbash Meinel	16 years ago

Older »