[Python-Dev] Identifier API (original) (raw)

Victor Stinner victor.stinner at haypocalc.com
Thu Oct 13 00:44:33 CEST 2011

Le samedi 8 octobre 2011 16:54:06, Martin v. Löwis a écrit :

In benchmarking PEP 393, I noticed that many UTF-8 decode calls originate from C code with static strings, in particular PyObjectCallMethod. Many of such calls already have been optimized to cache a string object, however, PyObjectCallMethod remains unoptimized since it requires a char*.

Because all identifiers are ASCII (in the C code base), another idea is to use a structure similar to PyASCIIObject but with an additional pointer to the constant char* string:

typedef struct { PyASCIIObject _base; const char *ascii; } PyConstASCIIObject;

Characters don't have to be copied, just the pointer, but you still have to allocate a structure. Because the size of the structure is also constant, we can have an efficient free list. Pseudo-code to create such object:

PyObject* create_const_ascii(const char *str) { PyConstASCIIObject obj; / ensure maybe that str is ASCII only? */ obj = get_from_freelist(); # reset the object (e.g. hash) if (!obj) { obj = allocate_new_const_ascii(); if (!obj) return NULL; } obj->ascii = str; return obj; }

Except PyUnicode_DATA, such structure should be fully compatible with other PEP 383 structures.

We would need a new format for Py_BuildValue, e.g. 'a' for ASCII string. Later we can add new functions like _PyDict_GetASCII().

Victor

More information about the Python-Dev mailing list