28
28
* Note that the entries themselves are strings, which already cache their
29
29
* hashes. So while there is a 1.5:1 difference in the time for hash(), it is
30
30
* already a function which is quite fast. Probably the only reason we might
31
* want to do so, is if we implement a KeyIntern dict that assumes it is
32
* available, and can then drop the 'hash' value from the item pointers. Then
33
* again, if Key_hash() is fast enough, we may not even care about that.
31
* want to do so, is if we customized SimpleSet to the point that the item
32
* pointers were exactly certain types, and then accessed table[i]->hash
33
* directly. So far StaticTuple_hash() is fast enough to not warrant the memory
36
37
/* This defines a single variable-width key.
37
38
* It is basically the same as a tuple, but
38
39
* 1) Lighter weight in memory
39
* 2) Only supports strings.
40
* It is mostly used as a helper. Note that Keys() is a similar structure for
41
* lists of Key objects. Its main advantage, though, is that it inlines all of
42
* the Key objects so that you have 1 python object overhead for N Keys, rather
40
* 2) Only supports strings or other static types (that don't reference other
46
44
#define STATIC_TUPLE_INTERNED_FLAG 0x01
47
#define STATIC_TUPLE_ALL_STRING 0x02
48
#define STATIC_TUPLE_DID_HASH 0x04
47
// We could go with unsigned short here, and support 64k width tuples
48
// without any memory impact, might be worthwhile
51
49
unsigned char size;
52
50
unsigned char flags;
53
51
unsigned char _unused0;
added
removed
bzrlib/_static_tuple_c.h
