Unicode charmap decoders slow

[Tony Nelson]

Is there a faster way to decode from charmaps to utf-8 than unicode()?

I'm writing a small card-file program. As a test, I use a 53 MB MBox
file, in mac-roman encoding. My program reads and parses the file into
messages in about 3..5 seconds, but takes about 13.5 seconds to iterate
over the cards and convert them to utf-8:

for i in xrange(len(card s)):
u = unicode(cards[i], encoding)
cards[i] = u.encode('utf-_8')

The time is nearly all in the unicode() call. It's not so much how much
time it takes, but that it takes 4 times as long as the real work, just
to do table lookups.

Looking at the source (which, if I have it right, is
PyUnicode_Decod eCharmap() in unicodeobject.c ), I think it is doing a
dictionary lookup for each character. I would have thought that it
would make and cache a LUT the size of the charmap (and hook the
relevent dictionary stuff to delete the cached LUT if the dictionary is
changed).

I thought of using U"".translate() , but the unicode version is defined
to be slow. Is there some similar approach? I'm almost (but not quite)
ready to try it in Pyrex.

I'm new to Python. I didn't google anything relevent on python.org or
in groups.
_______________ _______________ _______________ _______________ ____________
TonyN.:' *firstname*nlsn ews@georgea*las tname*.com
' <http://www.georgeanels on.com/>

[Martin v. Löwis]

Re: Unicode charmap decoders slow

Tony Nelson wrote:[color=blue]
> Is there a faster way to decode from charmaps to utf-8 than unicode()?[/color]

You could try the iconv codec, if your system supports iconv:

http://cvs.sourceforge.net/viewcvs.py/python-codecs/practicecodecs/iconv/

Regards,
Martin

[Tony Nelson]

Re: Unicode charmap decoders slow

In article <43410f1b$0$701 9$9b622d9e@news .freenet.de>,
"Martin v. Löwis" <martin@v.loewi s.de> wrote:
[color=blue]
> Tony Nelson wrote:[color=green]
> > Is there a faster way to decode from charmaps to utf-8 than unicode()?[/color]
>
> You could try the iconv codec, if your system supports iconv:
>
> http://cvs.sourceforge.net/viewcvs.p...ecodecs/iconv/[/color]

I had seen iconv. Even if my system supports it and it is faster than
Python's charmap decoder, it might not be available on other systems.
Requiring something unusual in order to do a trivial LUT task isn't an
acceptable solution. If I write a charmap decoder as an extension
module in Pyrex I can include it with the program. I would prefer a
solution that doesn't even need that, preferably in pure Python. Since
Python does all the hard wark so fast it certainly could do it, and it
can almost do it with "".translat e().
_______________ _______________ _______________ _______________ ____________
TonyN.:' *firstname*nlsn ews@georgea*las tname*.com
' <http://www.georgeanels on.com/>

[Martin v. Löwis]

Re: Unicode charmap decoders slow

Tony Nelson wrote:[color=blue]
> I had seen iconv. Even if my system supports it and it is faster than
> Python's charmap decoder, it might not be available on other systems.
> Requiring something unusual in order to do a trivial LUT task isn't an
> acceptable solution. If I write a charmap decoder as an extension
> module in Pyrex I can include it with the program. I would prefer a
> solution that doesn't even need that, preferably in pure Python. Since
> Python does all the hard wark so fast it certainly could do it, and it
> can almost do it with "".translat e().[/color]

Well, did you try a pure-Python version yourself?

table = [chr(i).decode(" mac-roman","replace ") for i in range(256)]

def decode_mac_roma n(s):
result = [table[ord(c)] for c in s]
return u"".join(result )

How much faster than the standard codec is that?

Regards,
Martin

[Tony Nelson]

Re: Unicode charmap decoders slow

In article <43419076$0$251 43$9b622d9e@new s.freenet.de>,
"Martin v. Löwis" <martin@v.loewi s.de> wrote:
[color=blue]
> Tony Nelson wrote:[color=green]
> > I had seen iconv. Even if my system supports it and it is faster than
> > Python's charmap decoder, it might not be available on other systems.
> > Requiring something unusual in order to do a trivial LUT task isn't an
> > acceptable solution. If I write a charmap decoder as an extension
> > module in Pyrex I can include it with the program. I would prefer a
> > solution that doesn't even need that, preferably in pure Python. Since
> > Python does all the hard wark so fast it certainly could do it, and it
> > can almost do it with "".translat e().[/color]
>
> Well, did you try a pure-Python version yourself?
>
> table = [chr(i).decode(" mac-roman","replace ") for i in range(256)]
>
> def decode_mac_roma n(s):
> result = [table[ord(c)] for c in s]
> return u"".join(result )
>
> How much faster than the standard codec is that?[/color]

It's .18x faster.
_______________ _______________ _______________ _______________ ____________
TonyN.:' *firstname*nlsn ews@georgea*las tname*.com
' <http://www.georgeanels on.com/>