Fredrik Lundh wrote:
>
> mal wrote:
> > UnicodeMappings: 1631.65 ms 90.65 us +42.76%
> > UnicodePredicates: 1762.10 ms 7.83 us +15.99%
> > UnicodeProperties: 1410.80 ms 7.05 us +19.57%
> > UnicodeSlicing: 1366.20 ms 7.81 us +19.23%
> >
> > Unicode mappings and other Unicode database related methods
> > show the effect of the compression of the Unicode database -- a
> > clear space/speed tradeoff.
>
> umm. the tests don't seem to test the "\N{name}" escapes, so the
> only thing that has changed in 2.1 is the "decomposition" method
> (used in the UnicodeProperties test).
The mappings figure surprised me too: the code has not changed,
but the unicodetype_db.h look different. Don't know how this
affects performance though.
The differences could also be explained by a increase in Unicode
object creation time (the concatenation is also a lot slower),
so perhaps that's where we should look...
> are you sure you're comparing against 2.0 final?
Yes... after a check of the Makefile I found that I had compiled
Python 2.0 with -O3 and 2.1a1 with -O2 -- perhaps this makes
a difference w/r to inlining of code. I'll recompile and rerun
the benchmark.
--
Marc-Andre Lemburg
______________________________________________________________________
Company: http://www.egenix.com/
Consulting: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4