[<<] Industrie Toulouse
I'm facing a nice little Python/Zope programmers dilemma. I have a critical "Zope" "Python" Script - Python code objects in Zope that are editable through the web, and are subject to being run in a "restricted mode" interpreter that enforces Zope security policies. It's quite long for a single script, weighing in at approximately 170 lines. But it does its job well, and is written with maintainability in mind (there's only one variable in there that I find non-obvious, and whose usage I might change).

Unfortunately, it seems to do its job slowly. I think there are a few contributing factors to this:

  1. Restricted Python. I think the security overhead is slowing the execution down. In evaluating the script's code, it doesn't really need to go through this.
  2. SQL Calls. There are a lot of calls into SQL Methods, both read and write. I'm not sure if this can be helped, or indeed is having any real noticeable effect on the speed.
  3. Generating/Sending Emails. I think there might be an issue here. The MailDropHost Product by Jens Vagelpohl could help as it sends mail asynchronously.

With those points in mind, I've started tackling the first bullet by moving the code into an External Method, where it is not victim to the Restricted Python interpreter. As a bonus, the code can be checked into CVS. But now I face a new dilemma - inline or breakout?

Since the code was originally written as a Zope Python Script, it was one big inline piece of execution. Now that it's an External Method, I have the opportunity to refactor, and turn the code into a class/singleton wherein the code is broken out into methods that are executed in a certain order. My newer instincts are pulling me in this direction. But I know that it brings in new overhead to the code whose speed I'm already concerned about. Now, instead of dealing with restricted Python, I'd have to deal with a number of new function calls and name lookups. And, possibly, Thread Safety issues.

The code in question is very central business logic. In order of importance, it needs to be solid, maintainable, and relatively fast. It succeeds on the first two points (very solid, fairly maintainable). The third one is a matter of some debate, most of which is going on inside my head. Future writings in this space will look at the avenues explored and if they yielded any results.