why python is slower than java?

[Maurice LING]

This may be a dumb thing to ask, but besides the penalty for dynamic
typing, is there any other real reasons that Python is slower than Java?

maurice

 

[Bryan]

This may be a dumb thing to ask, but besides the penalty for dynamic
typing, is there any other real reasons that Python is slower than Java?

maurice

at work, we use java and python. we have projects using swing and others using wxpython. we have applications that do
intensive io and others that do intensive cpu. we have not found that python is slower than java. in fact, when it
comes to gui's, our swing apps take "forever" to startup and when when garbage collector starts, the whole app just
freezes for about 15 seconds. our wxpython apps, start right up and "feel" faster and snappier. can you show an
example of where python's "slow" speed as compared to java's "fast" speed has negatively impacted your application or
has been noticable in any way? i know this is a trolling question you have posted, but i'm actually very interested
knowing why you have said this.

thanks,

bryan

 

[Maurice LING]

at work, we use java and python. we have projects using swing and
others using wxpython. we have applications that do intensive io and
others that do intensive cpu. we have not found that python is slower
than java. in fact, when it comes to gui's, our swing apps take
"forever" to startup and when when garbage collector starts, the whole
app just freezes for about 15 seconds. our wxpython apps, start right
up and "feel" faster and snappier. can you show an example of where
python's "slow" speed as compared to java's "fast" speed has negatively
impacted your application or has been noticable in any way? i know this
is a trolling question you have posted, but i'm actually very interested
knowing why you have said this.

thanks,

bryan

Thanks, lets just say that I have no interest in trolling.

1st of all, I thought it is somehow common knowledge that python is
slower than java in many cases. Though I may be wrong... When I do a
Google search, this came up...

http://twistedmatrix.com/users/glyph/rant/python-vs-java.html

although http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprtTR.pdf
showsjust the opposite.

What I need to work on now is something that requires speed (and dealing
with files), without user's intervention. So the part about users' delay
time is not in the equation. My choices boils down to Python or Java.

Cheers
maurice

 

[Bryan]

Thanks, lets just say that I have no interest in trolling.

1st of all, I thought it is somehow common knowledge that python is
slower than java in many cases. Though I may be wrong... When I do a
Google search, this came up...

http://twistedmatrix.com/users/glyph/rant/python-vs-java.html

although http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprtTR.pdf
showsjust the opposite.

What I need to work on now is something that requires speed (and dealing
with files), without user's intervention. So the part about users' delay
time is not in the equation. My choices boils down to Python or Java.

Cheers
maurice

but you aren't saying exactly _what_ requires speed and exactly what your requirements for the project is. you are being
way too general here for anyone to really help you. as for working with files, i much rather do that in python than
java. i may be wrong, but i thought java's file IO was pretty much a thin wrapper over c. so i don't think you will
have any speed problems with python's file IO compared to java's. also, just for fun, write the following fully
working python program in java:

import time
t = time.time()
s = open('in.txt').read()
open('out.txt', 'w').write(s)
print time.time() - t

(by the way...i was able to write the above lines of python code without referring to a manual

if it's not too much trouble, could you please post your code here along with the time results for the above code and
your java code? you can test a small file and a large one.

thanks,

bryan

 

[Christopher Koppler]

What I need to work on now is something that requires speed (and dealing
with files), without user's intervention. So the part about users' delay
time is not in the equation. My choices boils down to Python or Java.

Speed in what area? Dealing with files, is it a heavily I/O-based program?
If so, choice of programming language will very probably hardly impact
performance (well, depending of course on exactly you want to do, there
may of course be differences...).
Or do you want to crunch numbers? Python has great extensions for that,
written in highly optimized C. Come to think of it, Python has great
built-in datatypes and extensions for all manner of things, written in
highly optimized C. So even if your application wants to do some heavy
processing of <whatever> that doesn't depend on external factors like I/O
speed, the network or user interaction, Python will generally be fast
enough.
And as for the statically typed nature of Java providing speed benefits,
take a look at Psyco, which often (but not always) helps enormously.

So everything boils down to two points: what exactly you want to do - if
you can tell us that, someone better qualified and less biased than
myself might actually be able to offer you concrete advice on what to
choose - and as always: premature optimization is the root of all evil

 

[John Doe]

This may be a dumb thing to ask, but besides the penalty for dynamic
typing, is there any other real reasons that Python is slower than Java?

maurice

Hi Maurice,
the issue is compiling and bytecode. Python and Java compile source to
their own bytecodes. Bytecode is a binary that is portable between many
Operating Systems. Some time in 1999 (I think) IBM developed a jit or
Just In Time compiler for Java (Apple invented the JIT concept earlier to
make 68000 code work on their new line of PowerPC Macs).

The JIT compiler compiled java to both bytecode and native OS opcode. This
offered increase speed on the second + runs. The binary was suppose to be
compiled into a block containing bytecode and opcode. If the java runtime
noted that the opcode segment was 'native', it was suppose to run it, over
the bytecode. This gives the 'faster' perception.

Of course some company, afraid their developers might build there GUI apps
with java, over their native mode (thus making their application work
anywhere Java worked) went ahead and developed a version of the java
compiler that stripped out the bytecode. This made the binary
smaller, but locked it to one OS/arch. You can guess about which
corporation that was. Lawsuits followed. The company in question lost and
decided to drop Java for their own version of Java, JavaLite, sometimes
called 'see' 'sharp'.

Now as to speed... If you want speed, develop in Python or Perl to
get the form of your program. Development time is faster, even if the
execution is slow. Both provide OOP bindings. Once the program is up and
running, you can use profiling to determine which parts of your
interpreted code is slowest and most often used. These you rewrite as
C/C++ code and call them from within python.

In this way version 1.0 is all python. v1.1 has 20% C++; v1.2 is 34% C++
.... until v2.0 is all C++. Each upgrades is faster, but does not introduce
any new functionality and the risks that new functions imply.

If you were faithful to this concept, version 3 requires you to use the
oldest python branch who's functions will not be modified, to start
development. Could be v1.1 or 1.9.

C/C++ is for speed, not development.

Dan Atterton
(e-mail address removed)

 

[Israel Raj T]

This may be a dumb thing to ask, but besides the penalty for dynamic
typing, is there any other real reasons that Python is slower than
Java?

Do you have any data to support this ?
On Windows XP, Windows NT and Linux (Gentoo ), I have consistently
found python apps using wxpython to be far faster to load
and to be far more responsive than Java apps.

 

[Israel Raj T]

http://dada.perl.it/shootout/craps.html

On the CPU score, Java scores 28.4 while Python is within cooee at 27.
(bigger is better )

On the updated version at http://shootout.alioth.debian.org/craps.php,
Python beats at least two java implementations.

 

[EP]

John Doe wrote (posthumously?):

In this way version 1.0 is all python. v1.1 has 20% C++; v1.2 is 34%
C++
... until v2.0 is all C++. Each upgrades is faster, but does not
introduce
any new functionality and the risks that new functions imply.

If you were faithful to this concept, version 3 requires you to use the
oldest python branch who's functions will not be modified, to start
development. Could be v1.1 or 1.9.

C/C++ is for speed, not development.

Am I the only one to think this works, but makes no sense?

If one is to migrate their Python code to C++, one ends up with C++ code, which is great unless there is that (not so very rare) event where one wants to add new features, address new requirements, etc., etc. Applications need to evolve. If the finished code is going to be C++, one might just as well program in C++ from the start instead of aportioning mindshare between the two languages. Mindshare devoted to thinking in a second language might instead be devoted to thinking about the application.

Python seems to exemplify living code and since good applications have a life of their own, shouldn't the code live as well?

Dipping into C++ for program hotspots seems like good pramaticism, but at the expense of the simplicity and clarity that is otherwise Pythonic.

Fast Python is an answer, a patchwork of programming languages is a work around.


Eric

I won't say that Python needs to be faster, but imagine Python running as fast as C++ without any special tricks and you can envision the opportunities lost due to Python lacking blazing speed.

 

[Ian Bicking]

This may be a dumb thing to ask, but besides the penalty for dynamic
typing, is there any other real reasons that Python is slower than Java?

Python is generally late-bound, which means much more happens at runtime
compared to Java. For instance, consider accessing an attribute,
"self.x". In Java you know what the class is shaped like, exactly.
Usually this turns into some bytecode like "access the variable of self,
at offset 3". I don't know any of the details, but that's the general gist.

Similarly, there's many other optimizations where you can know at
compile time exactly what functions are called, how variables are
stored, etc. Using that information, you can do optimizations like
inline code. In the same places in Python, you are typically doing one
(or several!) hashtable lookups based on the variable or attribute name.

But even in Java there are limits. Because of interfaces and subclasses
you can know the shape of self/this, but you can't know the exact shape
of the objects around you (C++ is more aggressive in this respect, and
often can determine the exact shape; but in the process it's dangerous
to put together different pieces of compiled code when they don't know
about each other, which is why binary interfaces there are fragile).
Anyway, Java does a lot of the same stuff as Python when the exact type
is determined at runtime (which is frequently). This is where JIT comes
in, doing the optimizations at runtime; it is still limited, as it
cannot guarantee the type of the objects in the system, but must check
them each time before using the optimized path. And, actually, Python
can do the same sort of things with psyco. It's still harder in Python,
and the end result not as effective, but it's one among many tools.

If Java wasn't doing any optimizations, I don't think it would be
significantly faster than Python.

Also note that Python assimilates external (C, Fortan, etc) libraries
much better than Java seems to. In an entire system, Python can easily
be faster because Java includes many slow libraries (slow compared to
equivalent libraries available in Python). E.g., Swing is much slower
than wxPython.

Anyway, that's my take. I'm no authority, as I've never seriously used
Java, and haven't done any tests, nor spent anytime looking at the
bytecodes, etc.

 

[G. S. Hayes]

This may be a dumb thing to ask, but besides the penalty for dynamic
typing, is there any other real reasons that Python is slower than Java?

Personally, in practice I haven't found Python to be slower for real
apps, although it's sometimes an order of magnitude slower in
microbenchmarks. That's probably because a lot of things that could
be slow (e.g. numerical manipulation) are backed by C modules behind
the scenes in Python; it's also very easy to refactor Python code,
which sometimes leads to massive algorithmic improvements.

I will say that I still have a tendency to write some projects in C
when they seem to warrant it (e.g. the mathematics and video portion
of my realtime music visualization system--the UI and database work is
in Python).

(I also found Java's I/O on our platform to be dog-slow back in the
JDK 1.3 days, but I've not used it for anything significant since
then.)

 

[Terry Reedy]

This may be a dumb thing to ask, but besides the penalty for dynamic
typing, is there any other real reasons that Python is slower than Java?

To the extent that this is true, development money, though it is sometimes
amazing what unpaid or semi-paid volunteers have done with Python.

Terry J. Reedy
\

 

[John Machin]

1st of all, I thought it is somehow common knowledge that python is
slower than java in many cases. Though I may be wrong... When I do a
Google search, this came up...

http://twistedmatrix.com/users/glyph/rant/python-vs-java.html

Apart from the execution speed comparison, did you note that the
author took 4 x the time to write the Java, even though he had much
more Java experience than Python? Did you note that he severely bagged
Java reliability?

In any case, this article is comparing Python 1.5.2 and Java JDK 1.1
-- what does that tell you? If you need a clue, look at the date at
the bottom of the article; looks like 4.5 years old to me. Do you
think that either or both languages might have changed a little since
then?

Or is this a joke/troll?? I can't believe the "unimelb.edu.au"; surely
a forgery.

 

[Hans Nowak]

Or is this a joke/troll?? I can't believe the "unimelb.edu.au"; surely
a forgery.

Is it just me, or is the climate in c.l.py getting less friendly to
newbies? In any case,
http://www.zoology.unimelb.edu.au/staff/nicholas.htm mentions Maurice
Ling as an honor student.

 

[Lonnie Princehouse]

Yes, wxPython is typically quicker than swing. It's not fair to use
this in a generic Python-vs-Java speed shootout, though, since
wxPython is just a wrapper around wxWidgets' C++ code; you're really
comparing C++ vs. Java here. It does highlight the fact that it's
easy to write C extensions for Python, though.

AFAIK the major two reasons for Python's relative slowness are that
it's interpreted and dynamically typed.

There's almost always a convenience-for-speed trade-off, and Python is
certainly more convenient than Java

 

[Cameron Laird]

.
.
.

Operating Systems. Some time in 1999 (I think) IBM developed a jit or
Just In Time compiler for Java (Apple invented the JIT concept earlier to
make 68000 code work on their new line of PowerPC Macs).

.
.
.
John Aycock traces the technique back at least to 1960 <URL:
http://user.it.uu.se/~kostis/Teaching/KT2-04/jit_survey.pdf >.

 

[Mike Meyer]

Yes, wxPython is typically quicker than swing. It's not fair to use
this in a generic Python-vs-Java speed shootout, though, since
wxPython is just a wrapper around wxWidgets' C++ code; you're really
comparing C++ vs. Java here.

Is it unfair to compare Python dictionaries to Java HashTables because
Python is using hand-tuned C where Java is using Java? I'd say that's
a perfectly fair comparison. If that's fair, what's unfair about
comparing graphics toolkits that happen to be written in C rather than
Python (is there a graphics toolkit written in Python?).

That's *how* interpreted languages manage to compete with compiled
languages - they perform the common operations in hand-tuned compiled
code. That people tend to write Java libraries in Java rather than C
just means they're going to get slower libraries.

AFAIK the major two reasons for Python's relative slowness are that
it's interpreted and dynamically typed.

Java is interpreted just like Python is. The only difference is that
Java splits the compiler and VM implementation into two different
binaries.

<mike

 

[Steve Menard]

Is it unfair to compare Python dictionaries to Java HashTables because
Python is using hand-tuned C where Java is using Java? I'd say that's
a perfectly fair comparison. If that's fair, what's unfair about
comparing graphics toolkits that happen to be written in C rather than
Python (is there a graphics toolkit written in Python?).

That's *how* interpreted languages manage to compete with compiled
languages - they perform the common operations in hand-tuned compiled
code. That people tend to write Java libraries in Java rather than C
just means they're going to get slower libraries.




Java is interpreted just like Python is. The only difference is that
Java splits the compiler and VM implementation into two different
binaries.

<mike

Actually java has not been interpreted for quite a few years. Java today
is compiled to native code at runtime (JIT), exactly like what Psyco
tries to do for Python. This means the only things that (today) makes a
java program slower than a C program are Java's added safety features (
Bounds-checking on arrays and garbage collection to name but two).

Java's speed and Python's speed are not absolute values. Java IS faster
than python when it comes to CPU-intensive operations. IF you given
problem is heavily IO-bound, then python will be just as fast as Java.
Also, if you are writing a GUI application, your program will spend most
of its time waiting for user-input and not much difference will be
noticed. Python may even win out in that case since it's GUI are
typically platform-tuned C/C++ libraries wrapped in Python.


Steve

 

[Alex Martelli]

Is it just me, or is the climate in c.l.py getting less friendly to
newbies? In any case,

Interestingly enough, I sort of share your perception -- and I have
noticed the same thing, and seen it remarked upon by others, in other,
completely unrelated newsgroups as well, such as it.comp.macintosh.

It's not, I think, about newbies in general: people who come and post
help requests, without giving the information that's quite obviously
indispensabile to let us help them, keep getting treated with
unreasonable amounts of friendliness and courtesy even after many
requests for more info go unheeded, for example.

However, newbies who are clueless enough to come blasting in with the
usual whines we've heard a zillion times -- Macs cost too much, Python
is too slow, there's no apps for Macs, Python must absolutely add
feature X or it will die, Apple's gonna go broke tomorrow, etc, etc --
do appear to get on our collective nerves worse than their essentially
indistinguishable precursors did last year, two years ago, &c.

The accusation of being a troll often follows, breaking the old advice
to "Never attribute to malice what can be adequately explained by
incompetence". Maybe it's a case of the corollary to that old advice,
"Sufficiently advanced cluelessness is indistinguishable from malice".
But why that should be so this year more than last year, say, is not
clear to me...


Alex

 

[Maurice LING]

Interestingly enough, I sort of share your perception -- and I have
noticed the same thing, and seen it remarked upon by others, in other,
completely unrelated newsgroups as well, such as it.comp.macintosh.

It's not, I think, about newbies in general: people who come and post
help requests, without giving the information that's quite obviously
indispensabile to let us help them, keep getting treated with
unreasonable amounts of friendliness and courtesy even after many
requests for more info go unheeded, for example.

However, newbies who are clueless enough to come blasting in with the
usual whines we've heard a zillion times -- Macs cost too much, Python
is too slow, there's no apps for Macs, Python must absolutely add
feature X or it will die, Apple's gonna go broke tomorrow, etc, etc --
do appear to get on our collective nerves worse than their essentially
indistinguishable precursors did last year, two years ago, &c.

The accusation of being a troll often follows, breaking the old advice
to "Never attribute to malice what can be adequately explained by
incompetence". Maybe it's a case of the corollary to that old advice,
"Sufficiently advanced cluelessness is indistinguishable from malice".
But why that should be so this year more than last year, say, is not
clear to me...


Alex

I've already said the following and was not noticed:

1. it is a disk intensive I/O operation.
2. users delay is not in the equation (there is no user input)
3. I am not interested in the amount of time needed to develop it. But
only interested execution speed.

Thanks maurice