I’ve been trying some stuff with the Turbogears application I worked on a bit during the last two weeks.

First thing was that I looked into using postgres as DB backend for Turbogears. Which turned up a bug in sqlalchemy (an ORM, mapping objects to database rows and back). I was passing a unicode string to the getBy function (to retrieve an object by it’s primary key), and it went into the SQL statement without any quoting. Since my keys are all ascii, I could just cast them into regular string objects, and getBy worked then.

Performance with postgres is worse than with sqlite; this is not too surprising. However this might change once I enable multithreading.

Performance numbers: with SQLite: 8.30 trans/sec, with Postgres: 7.52 trans/sec

These performance numbers are still very bad, and I guess we won’t be keeping Turbogears on the long run, unless I find some documentation on improving the speed. One of the hints I got was to avoid py:match in kid, the templating engine used. I started by not using turbogears “sitetemplate” default template. This would automatically insert javascript and css files when needed. Since I don’t use their widgets and such, I havn’t been using this feature anyway. Not using the template - which contains one py:match for the ‘head’ tag and one for the ‘body’ tag - improved performance to 9.01 trans/sec (or 8.32 trans/sec)

Now I can’t explain why the improvements in the postgres run were better; both are a 10 minutes siege run. But 8.5% improvement is a start. I’ll look into getting rid of the other py:match instances in our templates. (If I’d only find a good example with py:def - guess I’ll instead “precompile” pre-templates into the actual templates or so instead with some self-written tool.)

P.S. No, I’ll probably not use turbogears for my next similar project. Rapid development is nice, ORMs are fancy and such, but sometimes good old plain SQL can be very easy to use, too. And more performant.