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

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

Rev	Summary	Authors	Date
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
4679.3.7	Document some bits I want to implement. Document some bits I want to implement.	John Arbash Meinel	15 years ago
4679.3.6	Default struct packing is aligning on 4-byte boundaries. Default struct packing is aligning on 4-byte boundaries. So we don't save any memory by using 'unsigned char' rather than 'long ob_size' on 32-bit platforms. And conforming to the standard size container means we interoperate better with other bits of code. We could probably work out 'PACK'ing macros, and do a bit better, though since malloc is going to work in certain sizes, it may not matter. At a minimum, though, we avoid the 12-bytes of GC object overhead per 'tuple', and we certainly avoid the tuple(tuples()) when dealing with parent lists.	John Arbash Meinel	15 years ago
4679.3.5	Have a pure-python implementation that works as tuples of tu... Have a pure-python implementation that works as tuples of tuples of strings, which is what we have today. There is a bit of extra overhead, as we now do type checking, etc. We may want to make the type checking optional...	John Arbash Meinel	15 years ago
4679.3.4	Remove get_key and treat things more directly as a tuple. Remove get_key and treat things more directly as a tuple.	John Arbash Meinel	15 years ago

Older »