mike watkins dot ca : September 13 2006 Archives

September 13 2006

Python 2.5c2 eeks out a little more

Of course I took Python 2.5c2 through an obligatory performance drill using QP, a Python web application framework. During the Python 2.5 beta period I had run these tests on Python 2.4 and 2.5b2 and found that the string, unicode, and other performance improvements in 2.5 contributed towards noticeable, evolutionary, improvement overall.

Putting qp through the wringer on an older server (1.26Ghz Intel, FreeBSD, 4GB RAM, fast disk) turns out results like this:

Req Content req/sec
Streams Length ab siege
1 10,000 474.68 318.62
2 10,000 741.50 478.94
4 10,000 783.53 447.83
8 10,000 796.81 424.24
16 10,000 771.57 419.02
32 10,000 754.92 413.27

For code like this:


class SiteDirectory (Directory):
    """
    A simple app for testing raw throughput with tools like
    `ab` and `siege`.
    """
    cache = None
    last_component = None

    
    def _q_lookup [html](self, component):
        """
        If component (n) is an int, return n random bytes, caching
        the result until component changes.
        """
        try:
            if component != self.last_component:
                self.cache = randbytes(int(round(float(component)/2)))
                self.last_component = component
            return self.cache
        except ValueError, e:
            raise ValueError( 
                 'To return n-length of random characters, supply an '
                 'integer in the URL instead of [%s].' % component)




Note to self: keep this around for comparing to future framework and Python revisions.

Python 2.5c2 is out

Python 2.5 release candidate 2 was pushed out today. FreeBSD ports has been already updated. To get yours:


portsnap fetch
portsnap update
cd /usr/ports/lang/python-devel
make install clean




Observations: I’ve run into no problems with 2.5 betas and release candidates, other than qpy needing a minor tweak for Python 2.5 due to a change in Python’s compiler code.

Other than that, the only external code I’ve had to patch for 2.5, so far, was due to non-ascii characters lurking about in source files (often in comments as attribution). As mentioned in the What’s New doc, non-ascii characters in source now raise a SyntaxError rather than a DeprecationWarning. Even though this change was long in coming and expected, I bet this trips up a fair number of packages. Fortunately, fixing this issue is easy for package maintainers.