Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] wrote: > > > I'm not sure whether this performance change is > > acceptable; at this point, I'm running out of ideas > > how to further improve the performance. > > without really digging into the patch, is it perhaps time to switch to > unboxed integers for the CPython interpreter ? > > (support for implementation subtypes could also be nice; I agree that > it would be nice if we had only one visible integer type, but I don't > really see why the implementation has to restricted to one type only. > this applies to strings too, of course).
In the integer case, it reminds me of James Knight's tagged integer patch to 2.3 [1]. If using long exclusively is 50% slower, why not try the improved speed approach? Also, depending on the objects, one may consider a few other tagged objects, like perhaps None, True, and False (they could all be special values with a single tag), or even just use 31/63 bits for the tagged integer value, with a 1 in the lowest bit signifying it as a tagged integer. - Josiah [1] http://mail.python.org/pipermail/python-dev/2004-July/046139.html _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
