Sunday, May 20, 2007

[off topic] Perl v. Python: Python Sucks!

Results of my non-scientific research: "Python sucks". Or rather Python performance does suck big time. Or rather lack of performance.

Simple test.

$ cat a.py
print "Hello world!"
$ time python a.py
Hello world!

real 0m0.039s
user 0m0.032s
sys 0m0.008s
$

Compare to this:
$ cat a.pl
print "Hello World!\n";
$ time perl a.pl
Hello World!

real 0m0.008s
user 0m0.004s
sys 0m0.004s
$

or this:
$ cat a.c
#include <stdio.h>
int main()
{
printf("Hello World!\n");
return 0;
}
$ make a && time ./a
gcc a.c -o a
Hello World!

real 0m0.003s
user 0m0.000s
sys 0m0.000s
$


I mean, what Python does those 40ms? Compared to Perl's 4ms? Or C's ZILCHms?

Absolute values seem to be small enough to be disregarded. But the same cliche can be seen in bigger applications.

For example Gentoo's tool chain - emerge - many Gentoo users are familiar with. Its DARN slow. Even compared to Debian system - apt-get - which does so much more and often labeled by jealous RedHat folks "amateurish" - works magnitudes faster (and even on junk hardware).

Or SCons. SCons take 1.5 seconds to just start up and print help message. It's Perl's sibling cons/pcons in the time manages to compile several sources.

6 comments:

Paddy3118 said...

What you are showing is mostly the time to load the interpreter. For a less biased look at relative benchmarking see The computer language shootout game, and don't forget to look up this page on how to make your language win!

If you looked here you'ld find a mainly Python program that is the fastest in its field.

Ihar Filipau said...

"What you are showing is mostly the time to load the interpreter."

That's why I have said "non-scientific research".

My reality is that most applications - markedly slow applications - are turning out to be Python applications.

My best guess is that many Python applications rely way too much on bloat - a-la Java - with bells'n'whistles like OOP for simple tasks like HelloWorld.

On other side, practical scripting languages like shell and Perl do not try to sell me a concept or better language. They are providing me with tool to do my work.

Uhm... I guess, on average, to Python programmer concepts and organization are more important than usability. Compared to bash/awk/sed/perl programmer.

And after all, if I'm writing tool for short repetitive task, I really not inclined to wait every time those NNNms Python interpreter takes to warm up. (And that's covers lion share of what I do.)

Somehow bash/awk/sed/perl do not need the warm up and always ready to execute whatever I throw at them.

P.S. I wonder would Python people ever consider to write PythonOS. JavaOS was interesting idea - killed quickly by Sun just in case. But it showed that it's possible to cut interpreter start-up times by simply having it all the time in memory, shared by all running applications. Idea was resurrected by Java servers - but only on server side (not on client one) and only for servlets.

Paddy3118 said...

I too am an awk, sed, perl, programmer and Perl does have its place, it's just used too much out of that slot. Personally I find 'speed' to be comparable between Perl and Python,; but Python ... well here is what I think in more detail.

On an OS written in Python: You would need to be able to compile at least a subset of Python into machine code - there are various projects looking at that, including PyPy
The OLPC project has a lot of Python, but not for the OS Kernel
- Paddy.

Ihar Filipau said...

> What's wrong with Perl

That's really - sorry - whining.

I'm using mostly Perl because "it works".

OK, I'm lying ;)

I use Perl because it allows me to do what I want with fewest hustles possible.

Looking at your post here -
http://paddy3118.blogspot.com/2007/01/data-mining-in-three-language05.html - I really can tell that Perl isn't your thing.

One does not "write programs in Perl" - one does "write programs with help of Perl". You have written in Perl - and to me frankly it looks more like BASIC. (*) Nowhere there I see you using Perl.

man perlvar && man perlsyn are your friends. Perl has many many tools to offer to you. Mastering them might take time - but the time will be repaid by work done quickly. With help of Perl. ;)

(*) Python example is also poorly written. Probably you didn't tried to put your best into the programs.

Paddy3118 said...

Unfortunately you seem to fall into the same mindset as others. No doubt you'll progress to writing larger Perl programs, need some of the features for writing, organising, and maintaining such large programs and either suffer with Perl as it gets further out of its depth, or change your language.

- Peace.

Ihar Filipau said...

"Unfortunately you seem to fall into the same mindset as others."

Or is it you? ;)

Development, organization & further maintenance have little to do with language itself.

They are all dependent on personal discipline.

In case of Python (or Java) you do not need to have discipline - you are firmly confined into language framework. Step aside - and compiler would complain.

In case of Perl (or C) you are absolutely on your own - it is your discipline as developer would be put to test.

Some people like former. Others like later. It's matter of personal tastes, ability to disciple ourselves and learning capacity. And also it is clear - from practice - that the division has little influence on amount and quality of work being done in the end.

WBR.

P.S. You would also notice same pattern with division IDE v. plain text editor: some people like to have everything prearranged once and learn it once (IDE), while others do not mind constant learning and constant rearranging internals of working environment to fit better to actual work at hand.

P.P.S. BASIC remark. Read statement of the task once again. Most of the time in the task you waste brining and organizing data in memory - while simple FSM (fed in on-line with data) would suffice. No saving of data required at all. If you want to save data - then use RDBMS and SQL. One SQL statement would be able to do the job in fraction of second. Though history would remain silent on how long would it take to INSERT all the data into DB. ;)