On Fri, 10 Mar 2006, Alec Flett wrote:
Ted Leung wrote:
Is it worthwhile trying to compile some of the smaller benchmarks on
Windows using gcc to get some idea of how bad off we are using GCC? We
could do release builds on the mac using either the IBM XLC compiler or on
Mac OS intel using intel's compiler
I'm guessing that trying to get chandler/wx building on a different compiler
is going to be a nightmare - not because of compiler incompatibilities, but
because getting all the Makefiles to do what we want is going to be extremely
tedious.. and its not clear to me if there is any benefit beyond confirming
that in fact VC++ is a better compiler than gcc.
Yeah, good luck getting the ./configure scripts to produce working Makefile
unless these compilers are option-compatible with gcc...
Also, since these compilers are not free (free as in libre) and probably not
free (free as in beer), this move wouldn't be well received in the open source
world, no ?
It seems like what we've determined is "the python benchmarks are slower on
mac than windows because of gcc" - and that this is probably true for all
What we've mostly determined is that the mac, the power-pc mac, is slower than
anything else. We've also determined that gcc produces slower code than vc++.
In either case, no news here. I'd be curious to see how fast Chandler runs,
natively, on the new intel macs once we can produce a functional build there.
python apps... but Chandler on Linux isn't that bad. While I think this was
a useful exercise so that we can have a baseline to compare windows to mac,
it doesn't really explain why the mac is also much faster than Linux. It
Mac faster than linux ?? Are you saying OS X is faster than Linux on the same
hardware ? are you saying Mac faster than Intel PC ? My Linux PC sure is a lot
faster than my Mac Powerbook...
sounds like we need to start focusing on chandler-specific stuff,
specifically wx and berkeleydb.
That is not chandler-specific. How about focusing on actual chandler code such
as the repository or the chandler app code, like we did towards the end of the
0.6 release cycle ?
How about making some benchmarks:
1) Resizing the chandler window (tests wx & wxPython, shouldn't have much
repository interference)
Sure !
2) in headless, loading 3000 items and accessing some values on them
About Berkeley DB on Mac OS X: I had found that it was slower there than could
be, in particular with caching added (!) and Sleepycat said it was a problem
with the OS. Then versions 4.3.29 and 4.4.20 came out and suddenly one has to
use cache or it is 6 times slower, and a little faster compared to without
cache in earlier releases. The plot has thickened a bit...
I suspect that the "loading of 3000 items and accessing some values on them"
benchmark is going to exercise a lot more repository code than Berkeley DB
code. I'm hoping to move more of that code to C for some significant speed
improvements during the 0.7 release cycle.
This might at least give us a clue if the problems are mostly in the UI, or
mostly in the database.
I suspect neither. They're most likely all over the place, in the 'death by a
thousand' cuts style. Nothing we can't overcome but no magic bullet to
resolve them either.
[As an aside: when I was doing the calendar performance work in 0.6, we got
benefits tweaking both the DB and wx - Andi did the db work of course and I
was focused on wx.
The biggest speed improvements during 0.6 came from tweaking the app
proper, not the db or wx. For example: using indexes to find relevant calendar
events within a time interval instead of iterating all calendar events
linearly in the entire repository. I suspect there are more such things to
come. For instance, we might make some significant improvements by avoiding
the use of unbounded collections that have little benefit except in an empty
repository such as the 'all' collection.
One thing I found was that the Python-to-C++ layer (SWIG) was a definite
bottleneck for drawing. It wouldn't surprise me if the slower
Yes, definitely. The code SWIG generates for wrapping python is thick, sticky,
needlessly slow and generally useless. For example, in PyLucene, the 5000 line
swig interface file translates into almost 60,000 lines of C++ and almost
3,000 lines of Python code. It turns out that *NONE* of the generated python
code is needed. All of that can be done in C++, using Python's C API and C
types API for the wrappers, thereby cutting out an entire layer of python and
python calls.
For PyLucene, I've just embarked on rewriting these wrappers by hand, using
only C++, in other words, not using SWIG for PyLucene anymore, with some very
encouraging results. Yes, that's a lot of boilerplate but it's not as bad as I
had first feared. :)
For example, instantiating a simple Java Object instance from python on my
1ghz powerbook g4 takes:
python -m timeit -s "from PyLucene import Object" "Object()"
with swig 1.3.28: 10000 loops, best of 3: 20.6 usec per loop
without swig : 100000 loops, best of 3: 4.19 usec per loop
Simple instantiation is about 5 times faster without swig...
gcc is making wx that much slower on the mac because the SWIG'ed code is, of
course, C++ and thus slow. I will try to write up a wiki page next week with
"lessons learned" from wxPython performance tweaking.]
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
