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

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

Rev	Summary	Authors	Date
3377.3.30	Can we avoid the extra _do_query in start_searching? Can we avoid the extra _do_query in start_searching?	John Arbash Meinel	16 years ago
3377.3.29	Revert the _find_any_seen change. Revert the _find_any_seen change. The overhead of combining the searchers swamps the benefits of combining the search.	John Arbash Meinel	16 years ago
3377.3.28	Try using _find_any_seen_ancestors, Try using _find_any_seen_ancestors, which pulls out the loop around find_seen_ancestors. This may not be a net win yet.	John Arbash Meinel	16 years ago
3377.3.27	some simple updates some simple updates	John Arbash Meinel	16 years ago
3377.3.26	Found a graph leak. Found a graph leak. Needed set.update() rather than set = The results were still correct, but it would generally cause a large leak into the rest of the graph.	John Arbash Meinel	16 years ago
3377.3.25	A few more minimal ancestry checks A few more minimal ancestry checks	John Arbash Meinel	16 years ago
3377.3.24	For some reason find_unique_ancestors is much slower than it... For some reason find_unique_ancestors is much slower than it should be. Start trying to assert that it doesn't access more ancestry than it needs to.	John Arbash Meinel	16 years ago
3377.3.23	Implement find_unique_ancestors using more explicit graph se... Implement find_unique_ancestors using more explicit graph searching. Copied a lot of the loops from the find_difference code, but could streamline it a bit for the different logic (we only have to track one side of the differences, not both) I need to do more complete testing on bzr.dev, but so far it looks pretty good.	John Arbash Meinel	16 years ago
3377.3.22	include some tests using the complex graphs include some tests using the complex graphs	John Arbash Meinel	16 years ago
3377.3.21	Simple brute-force implementation of find_unique_ancestors Simple brute-force implementation of find_unique_ancestors	John Arbash Meinel	16 years ago
3377.3.20	comment cleanups. comment cleanups. I looked at removing the extra find_seen_ancestors() calls as part of new_common_unique, but they turn out to be very beneficial.	John Arbash Meinel	16 years ago
3377.3.19	Start culling unique searchers once they converge. Start culling unique searchers once they converge. This shows a large improvement when there are lots of searchers.	John Arbash Meinel	16 years ago
3377.3.18	We don't actually use common_ancestors_unique, so get rid of... We don't actually use common_ancestors_unique, so get rid of it. It was meant to avoid redoing work, but pretty much had 0 hit rate.	John Arbash Meinel	16 years ago
3377.3.17	Keep track of the intersection of unique ancestry, Keep track of the intersection of unique ancestry, rather than checking it again all the time.	John Arbash Meinel	16 years ago
3377.3.16	small cleanups small cleanups	John Arbash Meinel	16 years ago
3377.3.15	minor update minor update	John Arbash Meinel	16 years ago
3377.3.14	Take another tack on _search_for_extra Take another tack on _search_for_extra All we really care about is getting to the point where all common searchers have passed the unique nodes. So start all unique searchers with as much ancestry as possible.	John Arbash Meinel	16 years ago
3377.3.13	Change _search_for_extra_common slightly. Change _search_for_extra_common slightly. The official statement is that you can stop searching common nodes once all common tips are ancestors of all unique nodes. We need to make sure that we stop the common searchers once they find nodes that are ancestors, and then we can only exit the common search loop when they have finished. All tests pass, need to see if it is still 'efficient'.	John Arbash Meinel	16 years ago
3377.3.12	Remove the helpful but ugly thunk Remove the helpful but ugly thunk	John Arbash Meinel	16 years ago
3377.3.11	Committing a debug thunk that was very helpful Committing a debug thunk that was very helpful find_seen_ancestors() should not be accessing the real_provider() as it should only be looking at the part of the graph that has already been accessed. However, in some of our final checks, the list passed in included some of the stuff we had only peaked at. This drops the time for "bzr status" after a simple merge down from 5.2s down to 1.76s. (Before this fix it was closer to 6-11s for my "improved" form).	John Arbash Meinel	16 years ago

Older »