On Sat, Sep 25, 2010 at 11:24:26PM +0200, Arnold Krille wrote: > On Saturday 25 September 2010 20:21:22 Joel Roth wrote: > > On Sat, Sep 25, 2010 at 01:00:29PM +0200, Arnold Krille wrote: > > > 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.) > > 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. 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 :-) > 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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
