[Dev] Performance Update: Why is Chandler slow on Mac?

Andi Vajda vajda at osafoundation.org
Fri Mar 10 12:02:38 PST 2006

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


More information about the chandler-dev mailing list