Started 2008-05-25 by hohehohe2@gmail.com.
Excerpts:
If char const* is passed to objecjt.attr(), it uses
PyObject_GetAttrStrng() or PyObject_SetAttrStrng(). If object is
passed to objecjt.attr(), it takes the object as a Python string
object and uses PyObject_GetAttr() or PyObject_SetAttr().
If attr() behaves like this, it can be useful when there are lots
of objects which you know have the same attribute name. You can save
time by first making a boost::python::object and passing it to every
object's attr() inside a loop.
I just made a bit of modification to boost:python locally and did a
quick test, like
test 1:
for(int i = 0; i < n; ++i)
{
omain.attr(attrname) = 444; //attrname is a char const*
}
test 2:
for(int i = 0; i < n; ++i)
{
object o = omain.attr(attrname); //attrname is a char const*
}
test 3:
for(int i = 0; i < n; ++i)
{
omain.attr(oaaaa) = 444; //oaaaa is boost::python::object that represents a string
}
test 4:
for(int i = 0; i < n; ++i)
{
object o = omain.attr(oaaaa); //oaaaa is boost::python::object that represents a string
}
and it reasonably reflected the difference between PyObject_*Attr() and PyObject_*AttrString.
test 1 :2783ms
test 2 :2357ms
test 3 :1882ms
test 4 :1267ms
test5: PyObject_SetAttrString(po_main, "aaaa", po_num444);
test6: Py_DECREF(PyObject_GetAttrString(po_main, "aaaa"));
test7: PyObject_SetAttr(po_main, po_aaaa, po_num444);
test8: Py_DECREF(PyObject_GetAttr(po_main, po_aaaa));
(po_ prefixed variables are PyObject*),
all inside each for loop, and the results were
test 5 :2410ms
test 6 :2277ms
test 7 :1629ms
test 8 :1094ms
It's boost 1.35.0, Python 2.5 on linux(gcc4.1.2).
I also did the same test on windows(vs8) and the tendency was not
so different.
[SVN r45918]
accomodate strange beasts like numarray arrays that return arrays that
can't be used as truth values from their comparison ops.
Fix numpy test for portability with old doctest (again!)
[SVN r35572]
