User asked me to look at the POGL/PyOpenGL benchmark thing again. So I added a few cProfile calls to the silly thing so I could actually see what's going on (why not just use profiling to start with? Why create opaque graphs of pointless data when you can have a full breakdown of where the time is spent? Sigh. Batteries included.)

Anyway, about 25% of overhead is low-hanging fruit, mostly the error-checking code (as expected), also some of the ctypes-array handling stuff (again, as expected). Approximately 50% of runtime in the benchmark is in the glFlush call... i.e. waiting for sync/transfer. Another 2% is just in calls to time.time. Something is wonky in there.

The benchmark is so poorly structured I just don't care enough to try to fix it or track down the glFlush issue with it. What is with all the global variables and while loops? Ick! I felt dirty just trying to fit the profiling code in there.

Oh, there's a cute section on why you should use Perl instead of Python at the end of their page... it's a hoot! Three different bullet points on the print statement as reasons to choose a language for 3D graphics. Dudes, relax, if someone "must use Python for OpenGL" ;) it's probably for reasons more critical than print statement formatting ;) :) . If you guys want to claim the speed crown in OpenGL bindings; feel free, I can take it; but don't beat up on the poor little print statement :) .