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

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

Rev	Summary	Authors	Date
4679.3.27	Shave some time in btree by caching the 'extend' object. Shave some time in btree by caching the 'extend' object.	John Arbash Meinel	15 years ago
4679.3.26	Changing ref_lists back into using tuple([Key1, Key2]) rathe... Changing ref_lists back into using tuple([Key1, Key2]) rather than Keys() brings us down to 648ms. So obviously there is a lot to be gained by improving the Keys constructor, and possibly the on-demand creation of Key objects from Keys is killing performance.	John Arbash Meinel	15 years ago
4679.3.25	Using Key_New() rather than Key(PyTuple_New()) gets us to 72... Using Key_New() rather than Key(PyTuple_New()) gets us to 720ms. It takes some gymnastics to get it to work, because we have to export the symbol and then find the .lib file to use it from the pyrex code. setup.py syntax doesn't seem to support that cleanly :( Going further, we'll have to update _flatten_node to support Key nodes, since right now it has some explicit 'is tuple' checks that fail.	John Arbash Meinel	15 years ago
4679.3.24	Implement Key_New like Tuple_New to create a key from a 3rd-... Implement Key_New like Tuple_New to create a key from a 3rd-party source. Have Keys_item() return Key types rather than tuples. Drops the time to 738ms, probably because we then mostly compare Key <=> Key, rather than comparing Key <=> Tuple.	John Arbash Meinel	15 years ago
4679.3.23	A bit more testing shows that we are comparing Key to tuples... A bit more testing shows that we are comparing Key to tuples fairly often. I wonder if it isn't something about Keys.__getitem__ returning tuples.	John Arbash Meinel	15 years ago
4679.3.22	It seems that optimizing Keys_hash is not the way to go for ... It seems that optimizing Keys_hash is not the way to go for 'bzr log' performance. Baseline bzr.dev time: 702ms Time with Key: 760ms Time with Key_richcompare: 751ms Time with Key_hash: 750ms Time with Key.hash (stashed hash): 750ms. Probably need some profiling, though hard to get accurate profiling at this level.	John Arbash Meinel	15 years ago
4679.3.21	Implement Key_richcompare directly, rather than thunking to ... Implement Key_richcompare directly, rather than thunking to tuples.	John Arbash Meinel	15 years ago
4679.3.20	Implement tp_traverse, and add a soft dependency on meliae t... Implement tp_traverse, and add a soft dependency on meliae to test it. Basically, gc.get_referents doesn't use tp_traverse if the object isn't being tracked. Which is ok, but not what we want here. Key isn't in GC because it is overkill for something that can never have cyclical references. So I implemented a get_referents in meliae that ignores IS_GC.	John Arbash Meinel	15 years ago
4679.3.19	implement slicing as a tuple thunk. implement slicing as a tuple thunk. Clean up a few internals that was causing problems. It seems that btree requires slicing. We should probably implement it directly, depending on what we need. It is also possible now for the internal extract_key to use a Key object, rather than a tuple.	John Arbash Meinel	15 years ago
4679.3.18	Copy the hash and richcompare implementations, and add some ... Copy the hash and richcompare implementations, and add some tests. Again, all of this is bootstrapped by the fact that there is an 'as_tuple' representation.	John Arbash Meinel	15 years ago
4679.3.17	Implement some of the sequence items. Implement some of the sequence items. This also revealed that we need to decref during Key_dealloc.	John Arbash Meinel	15 years ago
4679.3.16	Initial work for a Key class. Initial work for a Key class.	John Arbash Meinel	15 years ago
4679.3.15	Get rid of the Keys depth parameter. Get rid of the Keys depth parameter. We will favor creating a different type (Key) as I think it will be quite a bit more obvious what is going on.	John Arbash Meinel	15 years ago
4679.3.14	update btree_index for the new Keys api. update btree_index for the new Keys api.	John Arbash Meinel	15 years ago
4679.3.13	Switch from 4 entries to a single integer that holds 4 field... Switch from 4 entries to a single integer that holds 4 fields.	John Arbash Meinel	15 years ago
4679.3.12	Start introducing a depth parameter, this allows us to have ... Start introducing a depth parameter, this allows us to have keys which are ('key', 'one') as well as (('key', 'one'), ('key', 'two'))	John Arbash Meinel	15 years ago
4679.3.11	Get Keys into the btree implementation. Get Keys into the btree implementation. At the moment, it is used for the ref-lists, rather than being used for the keys themselves. This is because we don't have 'depth' information, so we don't know that a given Keys instance should be considered a singular Key. I'll probably hack together 'depth' support, rather than have a Key type, though either would be reasonable.	John Arbash Meinel	15 years ago
4679.3.10	Implement hash, again using the as_tuples() bootstrap. Implement hash, again using the as_tuples() bootstrap.	John Arbash Meinel	15 years ago
4679.3.9	Bootstrap a richcompare function using as_tuples. Bootstrap a richcompare function using as_tuples. This allows 'sorted()' etc to function properly.	John Arbash Meinel	15 years ago
4679.3.8	Implement an as_tuples() function, and use it to implement r... Implement an as_tuples() function, and use it to implement repr().	John Arbash Meinel	15 years ago