[Urwid] Urwid benchmarking tool and results

Ian Ward ian at excess.org
Sun Jan 14 20:32:06 EST 2007

Julien Muchembled wrote:
>> I don't really like my "solution" though -- It only works if you don't 
>> use any interesting Unicode characters.
> Indeed. Any line with a character that isn't in SAFE_ASCII_RE slows down
> the application a little more, at such a point that might be
> slower than
> Whereas in my tests, the solution with a cache is as good as the
> SAFE_ASCII_RE one and doesn't have this drawback.
> So at the beginning, I didn't like [48] and preferred Haypo's solutions.
> Now I don't know what to think, because I did my tests with Hachoir only.
> It's not surprising that the cache solution always works well but it may
> not be the case with other applications.
> Hard to say, but I doubt a cache would fail as much as SAFE_ASCII_RE.
> Haypo suggested 2 cache implementations.
> The first is so simple that it has a memory leak.
> And the second uses deque that appeared in Python 2.4.
> I've attached a third one that remains simple, without those problems.
> Even if this cache isn't a less awful hack that SAFE_ASCII_RE, I hope
> you will consider it.
> Haypo's urwid-unicode-v7.patch [1] (yes, it conflicts with [48]) is
> certainly a smarter approach.

One problem with caching the result of calc_width is that in order to 
fix ticket #7 we can't assume that the width of a string will be the 
same from one call to the next.

Once we display a character on the user's terminal we might detect that 
their terminal doesn't display that character the way we expected, and 
we need to adjust that character's width in the library.

Also, Rebecca's branch that implements the calc_width function in C is 
the best optimization for that part of the library in my opinion.  I am 
doing work on ticket #1 that will complement her work by eliminating 
most redundant calls to calc_width.  It doesn't make sense to cache if 
the number of cache hits are going to be significantly reduced by other 


BTW, I am very interested in reproducing some of the Hachoir benchmarks. 
  It would be great if someone would submit something like the 
bench_1.py program in contrib/trunk for Hachoir.  Look at the 
bench_record.py program in contrib/trunk for an example of how to record 
some user input.

More information about the Urwid mailing list