why python is slower than java?

[Roger Binns]

Alex Martelli wrote:
> Roger Binns <rogerb at rogerbinns.com> wrote:
>   ...
>> I/O is one area where Java is *very* different than other
>> environments. Java emphasises the ability to select at runtime
>> (typically from
>
> Python's dynamism at runtime is definitely one of its fortes.

We are talking about different things.  Once you have written
some nice big Java "Enterprise" app, you'll see the difference.
I am not talking about the type system.  It is more about how
Java applications are constructed.  There are multiple JAR files,
many many properties files and the end user/adminstrator can
change what happens and plumb them together by changing the
properties files.

You could do *exactly* the same thing in Python, but people don't.
That doesn't make either language right or wrong, just that the
emphasis and what is considered "normal" is different.

> Sure, since the semantics are different.  Which is why we have the
> makefile method of socket objects: for those occasions in which you
> want signature-polymorphism at the expense of the overhead of
> adaptation.

Yes.  The point is that Java I/O is always done in that polymorphic
way, whereas Python doesn't.  In both cases, you can do what the
other language does, but people usually don't.  But it does mean
that if you want to measure I/O performance, you have to decide
if you want to do it with code optimised for speed, or what is "normal"
in each language.

> Generators are a reasonably recent addition to Python, and I have no
> idea what you mean by stating that Python emphasizes typing more than
> Java does

I meant Python's typing mechanism ("duck typing").  Python programs
take advantage of that, just as Java programs take advantage of
the Java typing mechanism.  Python's is more defined by the absence
of pervasive programmer defined typing, whereas the Java one requires
the specification of type information for all names, and interfaces
are used a lot.

> Python frameworks.  And factory-based design patterns are everywhere
> in Python, of course; indeed, it's in Java that you see lots of 'new
> ThisClass' constructs which build an instance of some hardwired
> concrete class -- 

Java programs have *way* more factory stuff.  Just a different emphasis.

> Python's default makes it trivially easy to read most files in a
> single gulp, so it's appropriate in many cases; Java's makes it hard
> and slow to read ANY file, so it's never appropriate.

Your Java code was not representative of what an average programmer
would do in Java.  In fact it was a spectacularly bad example of
Java programming.  You can find bad examples of programming in
every language on the web.

>> If the language code is the same, then that claim boils down to
>> the Java Native Interface vs the Python C API.  In the case of
>> Java, I can see the claim having some relevance in multi-threaded
>> code since Java doesn't have the GIL.
>
> Python does, but drops it during blocking I/O operations so that the
> relevance should be just about the same in both cases.

Python will be worse with the penalty being based on how much concurrent
I/O is happening and how many processers the host has.  This is due to
the serialisation of the Python bytecode, and non-serialisation of the
Java bytecode.  My best guess that this will be a few percentage points
at a low number of concurrent I/O and probably up to 20% with
thousands.

(At this moment at work I am in fact dealing with this very thing in some
Python code and a form of proxy server).

> I did observe (at some point along the substantial chain of small
> benchmarks I and some other posters exchanged) that the 4:1 ratio in
> runtime in favour of Python exactly matched the 4:1 ratio in
> pagefaults, again in favour of Python, btw.

Page faults aren't a valid way of measuring this.  You don't incur page
faults for malloced/brk memory but you do for executable pagein, and
for mmap (usually).  Using executable pagein and mmap is better when
you have multiple instances of programs since they will share
system memory.  Again this all comes down to what the runtime
environment is optimised for.

> However, firms that choose not to release their business critical
> applications as open source are likely to require at the very least a
> non-disclosure agreement before they show you those sources, making it
> impractical to use those sources to meet your wishes.

That is missing my point completely.  If I wanted to write a ray tracer
and I could find them all over the net and in business success stories
in all languages, I would want to examine the innards of them to see
if I could do the same thing.

We have all heard the Yahoo Stores/Paul Graham/Lisp story.  I don't
think many people have seen that code.  Do you think you could do something
similar in Lisp?  Could you write a ray tracer in Lisp?  If you could
see examples of even unrelated applications, and their code, you would
have a better idea.  You would be able to judge if you could achieve
it with a team of 10 average programmers.  But without being able to
see the internals of at least some examples, your guess would have a
very high margin of error.

> As for your latter sentence, I've never met a programmer whose default
> assumption was that they would NOT be able to write code just as good
> as most anybody else's.

That only applies to languages they know or know about, and in many
cases also libraries (eg SQL, Persistence, Networking, Transactions).
Any programmer who believes they can write Yahoo Stores in Lisp just
as good as what Paul Graham and co did, when they don't know Lisp, have
no experience in that type of application, have never done credit
card processing etc is kidding themselves.  They may be able to
do so eventually, but it will take much time to learn.  They are
unlikely to be able to accurately estimate that time at the begining.

Using another example, do you think everyone who reads this group
could just go ahead and write Zope?

Roger