From: tismer at appliedbiometrics.com (Christian Tismer) Date: Sun, 25 Apr 1999 20:05:15 GMT Subject: Python too slow for real world References: <372068E6.16A4A90@icrf.icnet.uk> <3720A21B.9C62DDB9@icrf.icnet.uk> <3720C4DB.7FCF2AE@appliedbiometrics.com> <3720C6EE.33CA6494@appliedbiometrics.com> Message-ID: <3723757B.CF96D973@appliedbiometrics.com> Content-Length: 1723 X-UID: 357 "Magnus L. Hetland" wrote: > > Justin Sheehy writes: > > > mlh at idt.ntnu.no (Magnus L. Hetland) writes: > > > > > (And... How about builtin regexes in P2?) > > > > Um, why? I don't see any need at all for them to move from > > module-status to core-language-status. > [...] > > > > In all seriousness, what reason do you have for making that > > suggestion? I am willing to believe that there might be a good reason > > to do so, but it certainly isn't immediately obvious. > > Now, that's really simple -- because re.py is slow. I thought maybe > some of the slowness might be improved by a c-implementation, that's > all. Not too important to me... Now, true for re.py, but if you just care about speed, you can abuse the underlying pcre module which is compiled. For simple cases where I just needed to match something, the "code" attribute of a compiled re object can be used instead of the re object. I admit this is a hack, but it gave me a speedup of factor 3 for a simple matching case. pcre's speed seems to be in the same order of magnitude as regex was. In the long term, I think it makes sense to build the rest of re.py also into pcre. Then I still would not see any reason to embed its functionaliy into the language. ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home