利用者:Collad

提供: wiki
2012年2月12日 (日) 22:02時点におけるwiki>Colladによる版
(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)
移動先: 案内検索

Me

Hi, I'm a blender user who has made some small (but IMHO important ;-) ) code contributions to the Python based COLLADA exporter in 2.49x and the C++ based COLLADA exporter in 2.5/2.6. I'm really happy with the COLLADA exporter in 2.6 now, since it uses C++ and is much faster. A comparison: The C++ exporter needed in its worst case IIRC 2 seconds and the Python based 15 minutes. That means: 15*60 / 2 = 450. So the Python based exporter was 450 times slower. Thank god that's over :)

Ideasman42

Not sure this is a fair comparison, just because the 2.4x script was slow, doesn't mean a new python script will be as slow, from memory this script wasn't very efficiently written. You could compare 2.4x collada with FBX exporter speed and check on the difference. --Ideasman42 13:16, 10 February 2012 (CET)

Collad 14:02, 12 February 2012 (CET)

I foresaw already someone would bring that argument. But you can google for yourself and find it all over the web: Python is hundreds of times slower than C++!

A few examples:

Quote from the official python.org site

C++

Almost everything said for Java also applies for C++, just more so: where Python code is typically 3-5 times shorter than equivalent Java code, it is often 5-10 times shorter than equivalent C++ code! Anecdotal evidence suggests that one Python programmer can finish in two months what two C++ programmers can't complete in a year. Python shines as a glue language, used to combine components written in C++.

Quote End

Faster coding? A lot. In speed? No, it's explicitly mentioned as a glue language.

Speed comparison for special scenario

http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/ Result: Hundreds of times slower.

Speed comparison for a simple mathematical problem

http://stackoverflow.com/questions/6964392/speed-comparison-with-project-euler-c-vs-python-vs-erlang-vs-haskell The only interesting part could be: If we consider pypy, which seems to have a good JIT-Compiler. But this small example doesn't show what happens with complex memory management of larger memory chunks.

Other problems

As you already mentioned: A big cause of the python speed problem could be memory management issues, since python has a garbage collector which is maybe badly handled. Using it correctly can be tricky and destroying the advantage the python solution should bring: Simpler programming. Especially the COLLADA format, which has all the these elements pointing to each other. It's like many different leaves of trees, pointing to leaves of totally different trees. Handling that can be confusing.

--Collad 14:02, 12 February 2012 (CET)