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

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

Rev	Summary	Authors	Date
4593.5.37	Finish implementation tests. Finish implementation tests.	John Arbash Meinel	15 years ago
4593.5.36	a few more implementations of the interface. a few more implementations of the interface.	John Arbash Meinel	15 years ago
4593.5.35	Start working on a per-vf implementation test of find_ancest... Start working on a per-vf implementation test of find_ancestry. Turns out we need to do a bit more implementation to get that working. We also need to implement the find_ancestry() code on the Builder objects.	John Arbash Meinel	15 years ago
4593.5.34	Change the KnownGraph.merge_sort api. Change the KnownGraph.merge_sort api. Instead of being a tuple api, it is now an Object api. TIMEIT testing at least seems to say that _MergeSortNode.key is no slower than using a tuple. Allocating the nodes is also not much slower (especially since we already needed them.) In the end it makes for an api which, IMO, is much easier to use, so since performance isn't impacted, it is worth switching. Also, determined that we needed to implement the new get_known_graph... on the weave code.	John Arbash Meinel	15 years ago
4593.5.33	Late import tsort because it causes an import cycle. Late import tsort because it causes an import cycle.	John Arbash Meinel	15 years ago
4593.5.32	With the new api, we don't return 'sequence_number' anymore. With the new api, we don't return 'sequence_number' anymore. Nothing ever used it anyway, and branch.iter_merge_sorted... was stripping it out. No need to do the extra busy work.	John Arbash Meinel	15 years ago
4593.5.31	Fix bzrlib.missing to not directly load the graph, etc. Fix bzrlib.missing to not directly load the graph, etc. Look at bzrlib.annotate, but it needs to inject a node into the graph, which isn't supported yet.	John Arbash Meinel	15 years ago
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	15 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	15 years ago
4593.5.28	Cleanup pass Cleanup pass	John Arbash Meinel	15 years ago
4593.5.27	bit of cleanup passes bit of cleanup passes	John Arbash Meinel	15 years ago
4593.5.26	small cleanup, a bit of comment tweaking. small cleanup, a bit of comment tweaking.	John Arbash Meinel	15 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	15 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	15 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	15 years ago
4593.5.22	Conform to the direct merge_sort test. Conform to the direct merge_sort test.	John Arbash Meinel	15 years ago
4593.5.21	Bring in the changes to merge_sort. Bring in the changes to merge_sort.	John Arbash Meinel	15 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	15 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	15 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	15 years ago

Older »