[lxml-dev] build & performance issues with 2.0beta2

[jholg at gmx.de]

> thanks for the report.

I'm actually pretty late... sorry for that. Maybe I should set up s.th. like a nightly or weekly checkout/build/test/bench someday.

> Hmm, guess that's something to fix in Cython. The *LongLong() functions
> are a
> recent addition for safe type conversion.
> 
> The line numbers above differ from mine, though. Could you send me the
> source
> code of the lines that failed here?

 110149
 110150 static INLINE int __Pyx_PyObject_IsTrue(PyObject* x) {
 110151    if (x == Py_True) return 1;
 110152    else if (x == Py_False) return 0;
 110153    else return PyObject_IsTrue(x);
 110154 }
 110155
 110156 static INLINE PY_LONG_LONG __pyx_PyInt_AsLongLong(PyObject* x) {
 110157     if (PyInt_CheckExact(x)) {
 110158         return PyInt_AS_LONG(x);
 110159     }
 110160     else if (PyLong_CheckExact(x)) {
 110161         return PyLong_AsLongLong(x);
 110162     }
 110163     else {
 110164         PyObject* tmp = PyNumber_Int(x); if (!tmp) return (PY_LONG_LONG)-1;
 110165         PY_LONG_LONG val = __pyx_PyInt_AsLongLong(tmp);
 110166         Py_DECREF(tmp);
 110167         return val;
 110168     }
 110169 }
 110170
 110171 static INLINE unsigned PY_LONG_LONG __pyx_PyInt_AsUnsignedLongLong(PyObject* x) {
 110172     if (PyInt_CheckExact(x)) {
 110173         long val = PyInt_AS_LONG(x);
 110174         if (unlikely(val < 0)) {
 110175             PyErr_SetString(PyExc_TypeError, "Negative assignment to unsigned type.");
 110176             return (unsigned PY_LONG_LONG)-1;
 110177         }
 110178         return val;
 110179     }
 110180     else if (PyLong_CheckExact(x)) {
 110181         return PyLong_AsUnsignedLongLong(x);
 110182     }
 110183     else {
 110184         PyObject* tmp = PyNumber_Int(x); if (!tmp) return (PY_LONG_LONG)-1;
 110185         PY_LONG_LONG val = __pyx_PyInt_AsUnsignedLongLong(tmp);
 110186         Py_DECREF(tmp);
 110187         return val;
 110188     }
 110189 }
 110190
 110191


> 
> It seems to lack catalog support. I thought about adding that test or not.
> Looks like it's better to leave it out.

Is that my libmxl2 that's lacking catalog support? Or do these tests try to access s.th. from the web?


> I wouldn't dare to compare the numbers here, given a difference of 30
> tests
> (especially not knowing which ones are missing). If you get errors, it
> naturally takes (a bit) longer. Also, it seems to run much less tests, so
> I
> guess you either do not have ElementTree installed for the compat tests
> (though I actually think that's the case for both runs), or it just takes
> longer to search the (non-existing) catalogs, or ...
> 
> If you want real numbers, you should rather run the benchmarks.

Your're right, of course, I'm gonna do that. Got a little carried away as I could actually see the test count going up ever so slowly compared to my last build.
Btw I noticed that the file bench.py is missing, which the Makefile tries to invoke.

Is there any existing tools to compare logs of different benchmark runs? Guess I'm gonna hack up s.th. rather than check differences manually...

Thanks,
Holger
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail