On Sat, Jun 22, 2013 at 1:43 PM, Scott Dial <scott+python-...@scottdial.com> wrote: > On 6/22/2013 2:17 PM, Benjamin Peterson wrote: >> Many people have raised concerns about this change, so I've now backed it >> out. > > I think that change also goes with this change: > > http://hg.python.org/cpython/rev/f1dc30a1be72 > > changeset 84248:f1dc30a1be72 2.7 > Arrange structure to match the common access patterns. > > 1.1 --- a/Modules/_collectionsmodule.c > 1.2 +++ b/Modules/_collectionsmodule.c > 1.3 @@ -48,8 +48,8 @@ > 1.4 > 1.5 typedef struct BLOCK { > 1.6 struct BLOCK *leftlink; > 1.7 + PyObject *data[BLOCKLEN]; > 1.8 struct BLOCK *rightlink; > 1.9 - PyObject *data[BLOCKLEN]; > 1.10 } block; > 1.11 > 1.12 #define MAXFREEBLOCKS 10 > > , which seems like a strange micro-optimization, at best. > > Based on that structure, it would seem that neither BLOCKLEN being 62 > (previous value) nor 64 (the new value) make much sense. It would seem > best that sizeof(block) == 64, so BLOCKLEN should be (64 - > 2*sizeof(PyObject *)). Nevertheless, I am skeptical that any tuning of > this structure provides any meaningful performance improvement.
Actually the data buffer is an array of pointers too, so with the original BLOCKLEN value of 62, sizeof(block) would be 64 times sizeof(PyObject *). In the Py3 version of the source there's even a comment explaining this right before the #define BLOCKLEN. Raymond, can you explain? -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com