Python versus Perl

[Thorsten Kampe]

* Dieter Vanderelst (2005-09-06 18:03 +0100)
> I'm currently comparing Python versus Perl to use in a project that 
> involved a lot of text processing. I'm trying to determine what the most 
> efficient language would be for our purposes. I have to admit that, 
> although I'm very familiar with Python, I'm complete Perl noob (and I 
> hope to stay one) which is reflected in my questions.
> 
> I know that the web offers a lot of resources on Python/Perl 
> differences. But I couldn't find a satisfying answer to my questions:
> 
> 1 - How does the speed of execution of Perl compares to that of Python?

Of course Python is faster than Perl. It's the same reason why
Mercedes are faster than BMWs (or was it the other way round?).
 
> 2 - Regular Expressions are a valuable tool in text processing. I have 
> noticed that Regular Expressions are executed very fast in Python. Does 
> anybody know whether Python executes RE faster than Perl does?

Again: this question doesn't make sense. It's up to you to write your
Regular Expressions fast.
 
> 3 - In my opinion Python is very well suited for text processing. Does 
> Perl have any advantages over Python in the field of textprocessing 
> (like a larger standard library maybe).
> 
> I hope somebody can answer my questions. Of course, every remark and tip 
> on Python/Perl in texprocessing is most welcome.

http://gnosis.cx/TPiP/

"In case regular expression operations prove to be a genuinely
  problematic performance bottleneck in an application, there are
  four steps you should take in speeding things up. Try these in
  order:

  1.  Think about whether there is a way to simplify the regular
      expressions involved. Most especially, is it possible to
      reduce the likelihood of backtracking during pattern
      matching? You should always test your beliefs about such
      simplification, however; performance characteristics rarely
      turn out exactly as you expect.

  2.  Consider whether regular expressions are -really- needed
      for the problem at hand. With surprising frequency, faster
      and simpler operations in the [string] module (or,
      occasionally, in other modules) do what needs to be done.
      Actually, this step can often come earlier than the first
      one.

  3.  Write the search or transformation in a faster and
      lower-level engine, especially [mx.TextTools]. Low-level
      modules will inevitably involve more work and considerably
      more intense thinking about the problem. But
      order-of-magnitude speed gains are often possible for the
      work.

  4.  Code the application (or the relevant parts of it) in a
      different programming language. If speed is the absolutely
      first consideration in an application, Assembly, C, or C++
      are going to win. Tools like swig--while outside the scope
      of this book--can help you create custom extension modules
      to perform bottleneck operations. There is a chance also
      that if the problem -really must- be solved with regular
      expressions that Perl's engine will be faster (but not
      always, by any means)."