Re: Performance java vs. python
Daniel Fetchinson
>> >> features (code generation, error checking, etc.), and rely on them to
>> >> provide the high level of support needed to be reasonably productive
>> >> in heavy-weight languages (e.g. Java).
>> >>
>> >> On the other hand there are developers who much prefer to keep things
>> >> light-weight and simple. They like clean high-level languages (e.g.
>> >> Python) which are compact enough that you can keep the whole language
>> >> in your head, and require only a good text editor to be used
>> >> effectively.
>> >
>> >This distinction is IMHO not correct. If you took a look at Java, you
>> would
>> >notice that the core language syntax is much simpler than Python's.
>>
>> That's half-true. The problem is that you have to digest a much bigger
>> chunk of Java before you can start being productive. Consider how simple
>> it is to write a non-regex grep in Python. In addition, Python's object
>> model is simpler than Java's, not even talking about the contortions that
>> Java's static class model forces you into.
>
>
> I am new to Python. I am slowly realizing that Python might be a better
> choice when compared to java on the server side. Is there any performance
> comparison between Java and Python ? For example, if I use the J2EE solution
> vs. python (Django etc.) on the server side, would one perform better over
> the other ?
Benchmarks always test for a given feature. The available benchmarks
will most likely not test the feature relevant for your particular
application simply because there are about a gazillion different ways
of using a web framework. So the best you can do is simply test the
bottleneck part of your application and see for yourself, otherwise
you will be left with comments like "django is used at work because
it's faster for us" or "I use j2ee because performance is better for
my web app". When it will come to choosing your framework these will
help little to none.
Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Krishnakant
> Benchmarks always test for a given feature. The available benchmarks
> will most likely not test the feature relevant for your particular
> application simply because there are about a gazillion different ways
> of using a web framework. So the best you can do is simply test the
Bingo! there will be hundreds of threads on this mailing list and many
others which exactly do that. And it also serves as a great food for
those bashing birds who just need a spart to start a flamewar.
Till date I have worked with both languages into their core as will as
with many libraries for different tasks.
Fortunately I have some assessment for web frameworks which is based
mostly on my personal experience and partially on some obvious facts.
At the outset, I have seen that python's syntax is pritty clean and as
some previous mail said on this thread, it needs just a few hours and
the language is compact enough to fit in your head.
Readers might ask, "so how is this associated with performance boosting
etc?"
Quite a good question. You see, the scope for making quick and suttle
changes in the code should be wide enough and easy to do as wel.
Since python has such easy and clean syntax and with the idea of
"battries included ", it is much more quicker and easier to tune the
application for many things including performance.
Since I feel comfortable with the language I am confident enough that my
code won't break too much when I try to do some serious alteration to
the code. This alteration might now be to change the logic but to
improve performance. This is the challenge and python is such a
language that manipulating to this level is pritty doable in short
period of time.
Secondly, Java it seems comes with a lot of bagage which might be the
case with python as well. But some how I don't know, python seems to be
much light weight then java.
May be there are many technical reasons for this and at the web
application side it seems to be compact zippi and fast. Again this
might be my personal assessment,and specially with database driven
application, no language can be absolutely better than the other and as
rightly suggested, test it on the bottleneck issues and fine tune that
particular part. I have seen many apps migrating from ejb based
framework to python, particularly one I remember in pylons and the
feedback has been positive.
Another thing is that I personally like to use OOP *only* when needed.
Java would force me to write classes (add the over doing with static
functions ) for every thing I do including a small function just for
returning a connection object.
This again is a major reason for me to stick to python.
In addition python also can do the kind of work, j2ME can do and so I
don't think there is any serious reason for choosing java over python.
I am currently developing a major application and it is currently using
the twisted library for xmlrpc and there is a thin client in pygtk.
Right now we are in the process of moving it to turbogears2 and so far
performance on both the ends have been good.
happy hacking.
Krishnakant.
CTO
>
> AFAIK, for java on the client side, JVM performance is one of the critical things which has been tuned to death until now. Even Google's Android which uses Java for the programming
> language uses a Dalvik Virtual machine which was spefically designed to handle low CPU, memory and power environments. Similarly, Python can also be used to program on Nokia phones etc. > Of course programming natively (C/C++) would make a difference in environments where CPU, memory and power are a big constraint. Given the context, do we know how Python compares with
> Java or even native programming. What is the overhead of Python's interpreted code ? Some standard benchmarks would help compare apples to apples though it may not help deciding which > framework to choose.
>
> -mohan
Danger, will robinson- the dalvik jvm has precisely nothing to do with
standard
java. It uses the same syntax but otherwise operates entirely
differently. Don't
assume you'll get the same performance characteristics out of the
other common
jvm's.
Geremy Condra
namekuseijin
>>>> If you took a look at Java, you would
>>>> notice that the core language syntax is much simpler than Python's.
thanks for the laughs whoever you are!
--
a game sig: http://tinyurl.com/d3rxz9
David Stanek
> someone said:
>>>>>
>>>>> If you took a look at Java, you would
>>>>> notice that the core language syntax is much simpler than Python's.
>
> thanks for the laughs whoever you are!
>
I'm no Java fan, but I do agree that the core language is a bit easier
for people to grasp. I have also heard that from other developers as
well.
--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
Chris Rebert
> On Tue, May 19, 2009 at 5:43 PM, namekuseijin <nameku...@gmail.com> wrote:
>>>>>>
>>>>>> If you took a look at Java, you would
>>>>>> notice that the core language syntax is much simpler than Python's.
>>
>> thanks for the laughs whoever you are!
>>
>
> for people to grasp. I have also heard that from other developers as
> well.
Perhaps for those with a C/C++ background, but I doubt that's true
generally speaking.
Cheers,
Chris
--
http://blog.rebertia.com
Gunter Henriksen
inside the VM, then for a "server side" application, the
JVM is faster, and proportionally even faster when there
are more threads ready to do something.
When the VM has to do a lot of interaction with the
OS, then I think it is difficult to make general
statements about Java vs Python, because there is so
much dependency on how a particular library interacts
with the operating system or with a remote server.
For example a database driver which is doing a lot
of conversion between the data representation of the
database and the native representation of the VM may
chew up more time than anything else, and for CPython
that driver may be doing all that stuff in a C library
where the Java version of the driver may be doing it all
in the JVM and taking an order of magnitude longer.
It seems to me like the guts of the JVM and CPython
VMs are pretty comparable in terms of performance, and
both languages are amenable to taking advantage of the
performance of the VM.
Other than the library implementations for interfacing
with the outside world, for me the major performance
distinction is with concurrency. I tend to implement
solutions which rely pretty heavily on shared objects
and the java.util.concurrent facilities, and it seems
to me like the CPython VM is not able to easily provide
the level of simple clean shared object concurrency
support the JVM does. And my experience with the Python
"multiprocessing" module is that while it is better than
nothing, it does not seem to facilitate nearly the level
of efficient shared object support the JVM does.
namekuseijin
> On Tue, May 19, 2009 at 5:43 PM, namekuseijin <nameku...@gmail.com> wrote:
>>>>>>
>>>>>> If you took a look at Java, you would
>>>>>> notice that the core language syntax is much simpler than Python's.
>>
>> thanks for the laughs whoever you are!
>>
>
> for people to grasp. I have also heard that from other developers as
> well.
Really? Core language, eh?
Just take a look at just the summary of the Java language spec:
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html
Then compare with the summary for Python 3.0 language reference:
http://docs.python.org/3.0/reference/
Like comparing a mammoth to a zebra.
Besides, how is:
for( int i=0; i<10; i++ )
simpler than:
for i in (range(10))
?
Scripting languages like Python eventually led Java to provide a more
friendly for, which they call, quite appropriately, enhacedFor.
Here's it in action:
for (Map.Entry<String, Integer> e : histogram.entrySet())
in Python:
for e in histogram.items()
fun.
Here's a more complete example, available a bit down from:
http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.14.2
Map<String, Integer> histogram = ...;
double total = 0;
for (int i : histogram.values())
total += i;
for (Map.Entry<String, Integer> e : histogram.entrySet())
System.out.println(e.getKey() + " " + e.getValue() / total);
in Python:
histogram = ...
total=0
for i in histogram.values(): total+=i
for e in histogram.items():
print( e[0] + " " + str( e[1]/float(total) ))
yeah, surely a friggin' lot more complex... and we didn't even come to
use any of Java's HUUUGE APIs, just the core lang... BTW, I'm amused
that Java's string concatanating doesn't require an explicit cast from
the float result.
anyway, again, thanks for the laughs.
Ant
> anyway, again, thanks for the laughs.
I'm a Java developer in my day job, and I use Jython for testing out
ideas and prototyping, due to the way Jython makes writing Java so
much easier... Those examples were spot on - things weren't much
simpler before generics, as you had casting going on everywhere. Not
to mention the nice primitive / object divide to add to the languages
complexity.
And the libraries in Java... Compare cat implementations:
# Python
fh = open("myfile.txt")
for line in fh:
print line
// Java
...
BufferedReader reader = new BufferedReader(new FileReader
("myfile.txt"));
String line = reader.readLine();
while (line != null) {
System.out.println(line);
}
...
And that's without all of the class/main method boilerplate or try
catch block required due to checked exceptions.
I've taught both Java and Python, and the latter is far easier to pick
up and run with, from both a syntactic point of view and in the use of
the libraries.
namekuseijin
> # Python
> fh = open("myfile.txt")
>
> for line in fh:
> print line
>
> // Java
>
> ...
>
> BufferedReader reader = new BufferedReader(new FileReader
> ("myfile.txt"));
> String line = reader.readLine();
> while (line != null) {
> System.out.println(line);
> }
>
> ...
>
> And that's without all of the class/main method boilerplate or try
> catch block required due to checked exceptions.
Indeed, and it's so complex and such a manual burden that you even
forgot a further
line = reader.readLine();
inside your while block.
I find it completely unimaginable that people would even think
suggesting the idea that Java is simpler. It's one of the most stupidly
verbose and cranky languages out there, to the point you can't really do
anything of relevance without an IDE automatically pumping out lots of
scaffold code for you.
Aahz
namekuseijin <nameku...@gmail.com> wrote:
>
>I find it completely unimaginable that people would even think
>suggesting the idea that Java is simpler. It's one of the most stupidly
>verbose and cranky languages out there, to the point you can't really do
>anything of relevance without an IDE automatically pumping out lots of
>scaffold code for you.
Well, I wouldn't go quite that far; after all, I managed to integrate
BouncyCastle into a Java app without an IDE (or really knowing Java, for
that matter). But you have a valid point once the excessive generalizing
is removed. ;-)
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"A foolish consistency is the hobgoblin of little minds, adored by little
statesmen and philosophers and divines." --Ralph Waldo Emerson
Duncan Booth
> I find it completely unimaginable that people would even think
> suggesting the idea that Java is simpler. It's one of the most stupidly
> verbose and cranky languages out there, to the point you can't really do
> anything of relevance without an IDE automatically pumping out lots of
> scaffold code for you.
>
But that means Java programmers are obviously more productive than Python
programmers: they produce many more lines of code per day even if much of
it is boileplate or even automatically generated. Managers like that.
OTOH, I consider it a productive day if I end up with fewer lines of code
than I started with.
--
Duncan Booth http://kupuguy.blogspot.com
Sion Arrowsmith
A friend once justified a negative LOC count as being the sign of a
good day with the following observation:
Code that doesn't exist contains no bugs.
Code that doesn't exist takes no time to execute.
Code that doesn't exist takes up no space.
Code that doesn't exist doesn't need maintenance.
Once, when faced with a rather hairy problem that client requirements
dictated a pure Java solution for, I coded up a fully functional
prototype in Python to get the logic sorted out, and then translated
it. Even given the optimisations of manual translation, and being
able to dispose of one portion of the Python which Java supplied the
functionality for out of the box (thread timeout, I think it was),
the code grew by 200%. That was a very unproductive day.
--
\S
under construction
Lie Ryan
>> OTOH, I consider it a productive day if I end up with fewer lines of code
>> than I started with.
>
> A friend once justified a negative LOC count as being the sign of a
> good day with the following observation:
>
> Code that doesn't exist contains no bugs.
> Code that doesn't exist takes no time to execute.
> Code that doesn't exist takes up no space.
> Code that doesn't exist doesn't need maintenance.
Why not call a day productive when the UnitTest that passed has
increased or stayed constant with reduced LOC.
> Once, when faced with a rather hairy problem that client requirements
> dictated a pure Java solution for, I coded up a fully functional
> prototype in Python to get the logic sorted out, and then translated
> it. Even given the optimisations of manual translation, and being
> able to dispose of one portion of the Python which Java supplied the
> functionality for out of the box (thread timeout, I think it was),
> the code grew by 200%. That was a very unproductive day.
Jython ?
Sion Arrowsmith
>Sion Arrowsmith wrote:
>> Once, when faced with a rather hairy problem that client requirements
>> dictated a pure Java solution for, I coded up a fully functional
>> prototype in Python to get the logic sorted out, and then translated
>
>Jython ?
This was back during Jython's wilderness years (barely maintained at
2.1 while the rest of us were on 2.3, or something like that. Mind
you, you could argue it's four versions behind at the moment.) Plus, I
was the only Python-head in the company just then. Plus, I meant that
"client requirements dictated a pure Java solution": they required the
ability to do a code audit. It's amazing the number and variety of
people who've drunk the Java Kool-Aid.
--
\S
under construction
namekuseijin
> Duncan Booth <duncan.bo...@suttoncourtenay.org.uk> wrote:
>
> >namekuseijin <namekusei...@gmail.com> wrote:
> >> I find it completely unimaginable that people would even think
> >> suggesting the idea that Java is simpler. It's one of the most stupidly
> >> verbose and cranky languages out there, to the point you can't really do
> >> anything of relevance without an IDE automatically pumping out lots of
> >> scaffold code for you.
> >But that means Java programmers are obviously more productive than Python
> >programmers: they produce many more lines of code per day even if much of
> >it is boileplate or even automatically generated. Managers like that.
>
> >OTOH, I consider it a productive day if I end up with fewer lines of code
> >than I started with.
>
> A friend once justified a negative LOC count as being the sign of a
> good day with the following observation:
>
> Code that doesn't exist contains no bugs.
> Code that doesn't exist takes no time to execute.
> Code that doesn't exist takes up no space.
> Code that doesn't exist doesn't need maintenance.
Amusing tales. And very true too -- managers just love LOC and
straightjacket programming environments.
Here's what the father of Unix, Ken Thompson, said once about LOC:
"One of my most productive days was throwing away 1000 lines of code."
http://www.brainyquote.com/quotes/quotes/k/kenthompso254858.html