scripting languages vs statically compiled ones

kosh kosh at aesaeion.com
Thu Oct 28 20:12:00 CEST 2004


On Thursday 28 October 2004 11:04 am, beliavsky at aol.com wrote:
>
> Language       Type of Language     Execution Time Relative to C++
> C++            compiled             1
> Visual Basic   compiled             1
> C#             compiled             1
> Java           byte code            1.5
> PHP            interpreted          >100
> Python         interpreted          >100
>

My problem with these kinds of numbers is that they illustrate the whole 
problem of lies, damned lies and statistics. The numbers are probably fairly 
close to accurate but also not even in the right universe. In various 
benchmarks c,c++ etc are typically always faster then python programs by a 
huge ammount but remember that benchmarks are also very short overall and are 
very time intensive over those lines of code. On a regular application there 
is no time to do the kind of optimizations that you see in these benchmarks 
and if you tried the product would be far too late.

Lets say that python is 5x more productive then c just for the sake of 
arguement. So if the project took 2 months in python it would be 10 months in 
c. Now when it comes to optimization you have about 5x the code in the c 
version compared to the python version. So it is easier to profile and fix 
problems in the python version by a large margin however more important is 
fixing design errors. Because the code is much shorter in python and simpler 
overall it makes it easier to identify, see and fix design errors.

My experience has been is that while c,c++ etc are faster then python in 
regular applications I work with python is almost always a good deal faster. 

> I think Python is slower than C++ or Fortran for number-crunching,
> based on some experience with Numeric, but the speed factor is more
> often in the range of 2-10, not >100. McConnell's benchmarks are more
> general. I doubt the assertion that VB is as fast C++. Replacing a VBA
> function in Excel with a C dll can lead to big increase in speed.

I agree that replacing a single function with c and give an increase in speed 
and that there are classes of things that we have libraries for which give 
large increases in speed however the point is that all of those things can be 
called from python easily. So why write an entire program in a lower level 
language like c,c++, java, c# etc when you can write it in python in far less 
time? One the python version is done you can profile it, fix speed problems, 
debug it etc using far less resources. Once you have done all of that you can 
first use libraries if they exist to speed up  your program if still needed, 
code parts in a lower level language now that  you know exactly where the 
speed issues are or use something like psyco. Overall your programs will be 
far shorter, easier to read, easier to maintain, easier to debug, and just as 
fast if not faster. In my view just about anything other then a kernel or a 
device driver is premature optimization to write in a low level language 
barring other contraints.




More information about the Python-list mailing list