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

[Stefan Behnel]

Hi,

jholg at gmx.de wrote:
>> 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.

good idea. :)


> 110165         PY_LONG_LONG val = __pyx_PyInt_AsLongLong(tmp);

Ok, so this line failed with

	src/lxml/lxml.etree.c:110165: parse error before `long'

which lets me assume that PY_LONG_LONG is the usual "long long" on your
machine, which apparently fails in gcc 2.95.

Let me guess: your Python install was not compiled with gcc 2.95, was it?


>> 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?

Yes, or maybe just the catalog itself. I have the DocBook DTD locally in my
catalog under

	/usr/share/xml/docbook/schema/dtd/


> Or do these tests try to access s.th. from the web?

They shouldn't. Though, maybe, ...

Guess it's just best to switch them off. :)


> Btw I noticed that the file bench.py is missing, which the Makefile tries
> to invoke.

Ah, had forgotten about that target. Fixed.


> 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...

That would be very helpful. The benchmarks just output a whole bunch of
numbers, but I never got around to making anything more legible from them.
Maybe we should have some kind of an "ETstone" or something, that would output
a single number for ET performance. Or maybe one for parsing, one for
serialising and one for the API or something in that line.

Stefan