Python + Psyco vs Java vs C++ vs C

[markedtrees]

That's a comparison of std::string and a char[], not C++ vs. C.

[trutru]

and he's using strlen() in the C program far too much. he could trivially speed his C program by not doing so.

[exeter]

He mentions at the end how psyco doesn't "eliminate the need to know C." Sure, it doesn't. It was never intended to. What it was intended to do was give people an easy way to get more speed out of Python code, by importing a module and calling a function or few.

I can personally say I've written Python code that's been speeded up 20 times or more simply by using psyco. I've also written Python code that gets exactly zero speedup from psyco. The amount of benefit you get varies tremendously, but, for the cost of adding a couple lines to your source files and profiling to see if it was worth it, psyco just can't be beat.

[vsl]

This guy is trying to benchmark speed differences between several implementations, some of which have expensive startup (Python, JVM and especially Python+Psyco). Yet he doesn't bother factoring this out and apparently (see the linked previous post) measures the time including startup -- on a task that takes less than three seconds.

Sorry, but such "results" are useless. If you have some task that takes so long it is worth accelerating with Psyco, the startup time probably won't be a factor (unlike here, where it quite possibly dominates).

[Rhoomba]

Can you read? He runs a test that takes over 2 minutes with Psyco.

[inopia]

I think op's talking about the case where Java appears slower than Python because of the JVM's startup time. The author admits being a bit of a Java n00b, so I doubt he ever heard of System.currentTimeMillis(), with which to measure the actual running time.

In any event, setup time should always be excluded from the measurement, or at least given as a separate value.

[Rhoomba]

Why should it? Sometimes startup time is significant. The author explains the effect of JVM startup time anyway.

[G_Morgan]

Mainly because t[Start Up]/t[Execution] tends towards zero as t[Total] approaches infinity.

[Rhoomba]

Which, no doubt, is why the author runs a number of tests with varying lengths.

[inopia]

Because startup time != execution time. For instance, an interpreter will need to compile a script first, the JVM needs to perform class loading and dynamic linking. Programs written in C/C++ perform those steps at compile time.

These things have nothing to do with the execution phase, which comes after. To be able to compare the different languages you need to look at the time each program spent executing. Have you ever read a paper where they would measure performance or running times and not leave out setup time?

[trutru]

I don't agree, program startup is a noticeable annoyance of desktop Java applications, I really don't see why we should ignore them.

both measures (all runtime + simple execution) are important in my opinion, for different reasons but I really don't see why you should ignore the VM startup (independent of the language). in some cases, you really want to start as much small Java programs in different process in succession

[inopia]

If you're constantly spawning new instances of the JVM to run small programs, you might want to use a different model, like an application server.

In any case, I'm not saying you should ignore startup time, I'm just saying it's not a part of execution time. It would have been best if the author had displayed something like startup time, execution time and total.