On Fri, 2010-10-22 at 15:49 -0400, Andrew Henderson wrote:
>
> I have not run the test myself, but I suspect that the majority of the
> time being spent during the Python trial is being spent in the startup and
> shutdown of the python interpretter.
Startup and shutdown of Python interpreter is not that much different
than startup or shutdown of a Java VM. Which is why I code in Java for
webapps, that are already loaded and running. Things that do not involve
startup or shutdown of the JVM on invocation. If its a command, I do not
code that in Java, because of the startup/shutdown delay and overhead.
Most all use of java-config are one off uses. Output packages to create
a classpath for another, print out info about the env, etc. Its almost
never used as a running script, application, in the background, or
service. Its always invoked once. Thus startup time and shutdown of the
interpreter become a big issue, if not the main issue. Its specifically
the startup, shutdown and other overhead of Python at minimum that I am
seeking to avoid by recoding it in C ;)
In fact when java-config (written in Python) performance improves its
because of data being cached in disk operations. At a much lower level,
and nothing to do with Python at all, which is starting and stopping on
every run.
Even when java-config is called by portage, which emerge is also written
in python, there are still delays. Even though a python interpreter is
already running a separate parent process. Children are creating
multiple python instances. Even though one is child python process of an
already running python parent process. You still get another instance of
Python, with its start up and shutdown delays.
> I would not expect the time spent executing the actual Python
> scripting to be the cause of such slow performance.
I might make some test case for comparison as I go to code in the
functionality. Then I can test function against function, apples to
apples. However even then, there is likely more memory and CPU overhead,
even if processing times are the same. There is still more overhead in a
Python app than C.
After all what is Python written in? Likely the same thing Java JVMs,
Ruby interpreters, Perl interpreters and many other things are written
in ;)
But I am not really seeking to do apples to apples in a functionality
sense. I am seeking to compare the entire command and its uses as whole,
in a practical real world scenarios. Even if functional performance is
the same. If real world usage performance differs. That is what matters
end of day.
> An apples-to-apples comparison on the performance would be
> to perform something like the following for both Python and C:
>
> struct timeval startTime, endTime;
> gettimeofday(&startTime, NULL);
> for (int i=0; i <= largeNum; ++i)
> {
> /* Perform task to be profiled */
> }
> gettimeofday(&endTime, NULL);
> /* Output the result of endTime - startTime */
Problem is your not really doing any real work. I want to see the
difference in performance for real work being done. Which invoking a
command and outputting help is real work, or usage.
If in Pythons case it must startup and shutdown the interpreter to
output help. Thats a negative for how Python is designed and works, and
IMHO should not be used to code commands. Interpreted languages for
commands is bad, for a service, background, or already running app thats
another story.
Its also why I am not recoding java-config in Java ;) Because there will
always be a startup and shutdown of the JVM, another interpreter.
> This eliminates the time overhead of the startup and shutdown of the
> process and only measures the actual work.
Most all of what I am seeking to recode are things that involve startup
and shutdown for every invocation. Even if the real work is the same,
its the startup shutdown overhead that will be a deal breaker ever time.
> Or, you could compile the
> binary with -pg and run gprof on the resulting call graph to get a more
> accurate picture.
Thanks for that info, I was curious about profiling the apps as I
develop them. Not only for comparison, but optimization.
> You are right that the scripted version will be slower, but it won't be
> anywhere near as slow as the numbers of your test suggest.
Is there ever a justification for slower, even if slightly? So its a few
seconds slower. That adds up on ever run, and if doing several
operations back to back. Those pennies of time add up :)
--
William L. Thomson Jr.
Obsidian-Studios, Inc.
http://www.obsidian-studios.com
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and is
protected by law. If you are not the intended recipient, you should
delete this message.
Any disclosure, copying, or distribution of this message, or the taking
of any action based on it, is strictly prohibited.
---------------------------------------------------------------------
Archive http://marc.info/?l=jaxlug-list&r=1&w=2
RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml
Unsubscribe [email protected]
