A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-July/005581.html below:

[Python-Dev] Problems with the new unicodectype.c

[Python-Dev] Problems with the new unicodectype.cFred L. Drake, Jr. fdrake@beopen.com
Thu, 6 Jul 2000 10:33:23 -0400 (EDT)
Fredrik Lundh writes:
 > Just noticed that _sre.c takes ages to compile on my linux
 > box, and comes out as a 450k object module.
 > 
 > it's under 30k on Windows.

  Wow!  Maybe try turning off optimizations?  I think there's an
option to just turn off inlining, bt I don't know if you can limit the
number of recursive inlines.  A simpler option: surround the "inline"
directive with #ifndef __GNUC__ / #endif.

 > Methinks gcc expands recursive inlined functions a bit more
 > than visual C.  I'll try do get it down under 100k before the
 > final release...

  Now, if we could do that for unicodedata and ucnhash, a lot more
people would be happy!
  Marc-Andre, Bill:  Would it be reasonable to have perfect_hash.py
actually compress the text strings used for the character names?
Since there's such a limited alphabet in use, something special
purpose would probably be easy and do a lot of good.  When checking
the lookup, you could easily decode the string in the table to do the
comparison.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




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