Mark Dickinson <dicki...@gmail.com> added the comment: Some comments, while I remember:
* the argument to _Py_HashPointer is not always divisible by 8. It's called to create hashes for various objects, including methodobjects; see the line: y = _Py_HashPointer((void*)(a->m_ml->ml_meth)); in meth_hash in methodobject.c, for example; here ml_meth is a C function pointer. I can't see how this could be a problem, though, especially as is seems very unlikely that two function pointers could be less than 8 bytes apart. * following from the above, it's also pretty unlikely that any two object pointers will be less than 16 bytes apart, so it might be worth seeing if performance with >>4 is noticeably any different from with >>3. * we should make sure that the value returned by _Py_HashPointer isn't the illegal hash value -1 (though it's difficult to see how it could be). One safe way to do this that shouldn't cost any CPU cycles would be to cast to unsigned long before the right shift, to be sure that the right shift zero-extends instead of sign-extending, so that the result is guaranteed nonnegative. * It *would* be nice to do something about the SIZEOF_LONG < SIZEOF_VOID_P case: the current conversion to a PyLong seems like quite an expensive way to go. And I've just ordered a computer with 64-bit Windows installed... _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5186> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com