26 Sep
2010
26 Sep
'10
6:46 a.m.
On Sat, Sep 25, 2010 at 11:24:26PM +0200, Arnold Krille wrote:
On Saturday 25 September 2010 20:21:22 Joel Roth
wrote:
That seems like a great way to develop applications.
I mention perl's profiler, because in developing Nama,
it was quite convenient.
I developed functions naively, without caching
provisions. When I noticed it was running slow for
hundreds of tracks, Devel::NYTProf showed me
exactly how many subroutine calls were taking
how much time.
Porting time-critical functions to c/C++ hasn't been
much issue for me, since I already use a speed
optimized engine for audio processing (Ecasound :-)
On Sat, Sep 25, 2010 at 01:00:29PM +0200, Arnold
Krille wrote:
Hm. The idea I mainly have in mind is not to optimize your python code, but
prototype your app with its functionality in python and when all works as
expected (more or less), port the time-critical parts to c/C++. Not because
python is slow (it is compared to native asm) in general, but because it is
definitely to slow for various tasks like audio. Porting parts of your python project to C/C++ is
easy (think prototyping
in python and port to compiled-language once the interface is finished
and the optimizations begin).
For optimizing perl, we have Devel::NYTProf, which
profiles the time spent in each subroutine. (As the name
suggests, the New York Times underwrote the development
costs.) And because python afaik still
has the big interpreter lock, effectively suppressing any python multi-
threading. Which you work around by re-implementing your heavy-math parts in C
and run them outside the interpreter lock (but still from within threads
created and managed from python)...
What, no native threads. Mock horror!
Best,
Joel
Have fun,
Arnold
--
Joel Roth