why python is slower than java?

[Jacek Generowicz]

Hehe. I'm really not trying to start a flame war, honest
I don't even like Java.

My point was just that it's sort of misleading to say "wxPython is
faster than Swing, therefore Python tends to be faster than Java for
all things".

OK, how about this:

C is faster than Java, and Python is just a wrapper around C, ergo
Python is faster than Java for all things.

x 10

 

[Lonnie Princehouse]

OK, how about this:

C is faster than Java, and Python is just a wrapper around C, ergo
Python is faster than Java for all things.

x 10

Works for me. It should also be noted that Python is _way_ more
Pythonic than Java is.

 

[Y2KYZFR1]

I am wondering the impact when IBM decided that the base memory to not
exceed 64kb, in the late 1960s...

I suppose more experienced people in this list can agree that certain
decisions made can be almost an edict. So, there is a re-building
process every now and then, hopefully to by-pass such edicts. Python
itself is already such an example.


Are the codebase of Python 1.5.2 and Java 1.1 totally replaced and
deprecated?

yes it has, in both cases : proof again that you don't understand
enough to comprehend why your question is irrelevant, and that you
can't understand the answer as such.

you can't compare something from so many years ago to each other and
then EXTRAPOLATE the results to NOW.

It would be like comparing a 1965 Mustang to a 1965 Corvette and then
coming to the conclusion that you could EXTRAPLATE those results to
compare the 2005 models. Just completely lacking in any understanding
of scientific theory.

Lisp compiler is the 1st compiler to be created (according to the
Red-Dragon book, I think) and almost all others are created by
bootstrapping to LISP compiler. What are the implications of design
decisions made in LISP compiler then affecting our compilers today? I
don't know. I repeat myself, I DO NOT KNOW.


Certainly I do not have 15 PhDs in computer science or computating
mathematics...... I suppose there are some syntax error in your
statement to allow me to parse it completely. "too vague", not "to vague".

an this just proves that YOU are irrelvant also, go troll somewhere
else. PLONK

 

[John Machin]

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.

No it doesn't. It says "honours student", which indicates solely the
enrolment status, with none of the connotations of merit that might be
attached to the American phrase "honor student".

To the main point: I apologise profusely to the whole world for
starting the thread of the month by not putting "Please turn your
irony detectors on" at the top of my post.

 

[Jon Perez]

First of all, I really really really love Python but unlike
the other people posting on this thread I am not allergic
to criticisms of python and I feel the attitude of
some on this list is way too defensive and actually
works against the outside perception of the language.
(OTOH, what I saw on this thread is still considered mild,
you should see those LISPers defend their language! :-D )

Anyway, on to the topic at hand. I actually don't
believe python is slower than java. But truth to
tell, the answer can never be a simple 'one is faster
than the other'.

In the cases where Python is slower than Java, it
is because Java is JIT-compiled whereas Python by
default is bytecode-interpreted (unless you use Psyco).

In the cases where Python is faster than Java, it
is because much of Python's core and library functionality
is actually coded very efficiently in C, and said
code path is using much of this functionality.

When it comes to the language proper, Java is just
way more primitive than Python, and considering
that the speed of both will be *** of roughly the same
order ***, I'll take Python any day.

The fact that you can much more easily use and write
Python C extensions (still not exactly a picnic though)
than JNI ones is yet another speed-related thing in
favor of Python over Java.

 

[Jon Perez]

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

1. it is a disk intensive I/O operation.

I see no reason why disk I/O bound operations should
be slower in Python than in Java. It's the same
C API calls underneath and very little bytecode
interpretation is going on when it is being done.

 

[Dan Perl]

Maurice,

As a member of this group, I regret the comments that you got from
"Y2KYZFR1", whatever his name is and whatever his real email address is.
Please do not let it affect you and please do not let it affect your view of
the group in general.

Dan

 

[developerchina]

hehe

(e-mail address removed) (Alex Martelli) wrote in message

[A]sking for tolerance and patience
against _rude_ newbies which barge in with shrill, mostly unjustified,
repetitious complaints, is, I think, a rather far-fetched request.

That request is in no way far-fetched if made to someone of great
personal maturity and character. Rudeness is hardly ever an effective
response to rudeness. So I'll make it: "Please be tolerant and
patient of newbies, _especially_ the rude ones." Remember it's the
audience, not merely the opponent you are addressing.

Be that as it may, Maurice's original question, while arguably founded
upon a false presumption, was in no way rude. Nor were his subsequent
posts (unless I missed one). The helpfulness of this newgroup should
be (and was) one of python's selling points. Certainly I learned much
here, and especially from your posts Alex, when I first started using
the language.

 

[fuzzylollipop]

yeah, but a lie unanswered by the truth becomes the truth.

you state opinon as fact and someone comes along reads your statement
that Python is so much slower and believes it is true because there is
no disententing voice to say, wait just a sec, this guy is clueless and
has no idea what he is talking about and here is why.

learn how to ask questions instead of stateing opinions as fact and you
might get a better response.

if you had said, is Python really as slow vs Java as these 3 year old
benchmarks seem to suggest, and then post what your own findings were
and that might prove DISCUSSION instead of posting in a Trolling sort
of way.

No matter how many times you say you are not trolling and continue to
post trolling style posts will make it true.

 

[Jeremy Bowers]

yeah, but a lie unanswered by the truth becomes the truth.

You know, it's bad enough that somebody starts this thread anew about
every two months anyhow, do you really have to try to resurrect dead ones?

Be patient and I'm sure you'll have many more opportunities to post this
general thought in a more timely fashion in the all-too-near future.

 

[Jeremy Bowers]

As for non desktop apps, the entire portage system of Gentoo is written in
Python. 'emerge sync' causes a python app to synchronise a local
application database with database at a non-local mirror. It is i/o
intensive and appears to work very well and very fast.

"emerge sync" mostly runs an rsync command (at least on standard
installs). The python contribution to that process is minimal.

The primary slowdown with "emerge" appears to be the way the database is
stored as many thousands of little files in /usr/portage. Again, not
really python; you want to accelerate emerge, speed up your hard drive.

(They have more cached metadata now at least in the cutting-edge release,
but as that is the one I use I don't know if that is now considered
stable. It has really sped things up. A couple more iterations and Python
might actually become the bottleneck.)

 

[JanC]

Eric S. Johansson schreef:

nothing would compel anyone to pay anything. But I could see eventually
folks being rated on whether or not they do pay. If you've got someone
who's always asking time-consuming questions and not paying anything, it
would be totally appropriate to filter out that person.

That person might be a student in some third-world country...

 

[Andrew Dalke]

JanC:

That person might be a student in some third-world country...

Then think of the extra incentive to provide useful answers.

Also, Eric had pointed out that payment included "money,
sex, chocolate" and other non-monetary possibilities.

Personally I think it'll be hard to put a monetary micropayment
into place because at that level those other factors have at
least a comparable impact.

Andrew
(e-mail address removed)

 

[JanC]

Andrew Dalke schreef:

Then think of the extra incentive to provide useful answers.

Also, Eric had pointed out that payment included "money,
sex, chocolate" and other non-monetary possibilities.

Personally I think it'll be hard to put a monetary micropayment
into place because at that level those other factors have at
least a comparable impact.

Heh, payment to an American --> equivalent American price for Belgian
chocolate --> Belgian price for Belgian chocolate --> this will be very
cheap for me and the other Belgians around here... ;-)