Soni and I got an invitation to the opening party for HackLab in Toronto,but I was out of town at a client site that night. However, the club has an open house on Tuesday nights, so I decided to drop in this evening to check them out. Spent much of the time talking with Sam, who is writing his own language, discussing the various strengths and problems of Python, Lisp, Prolog, C, C++ etceteras. Sam invited me back on Thursday for the Python night.
Spent the evening working on PyOpenGL/OpenGLContext. I wrote a tiny C extension that gets the data-pointer from a numpy array, which seemed to speed frame-rates by about 2x, sigh. The creation of a separate "ctypes" object to get the (integer) pointer for the array is all that optimized. If the numpy array just had a ".data" attribute that was the pointer-as-integer I could use that, but for some reason it seems to use a property instead. If I could find a way to optimize away the ctypes null pointer object creation as well I could probably get another significant boost (these functions are called hundreds of thousands of times/minute).
Also found a few hot-spots in, for example, the routing code, where it looks like there may be some algorithmic failures... the routing code is just so fast I hadn't noticed them particularly. The other huge slowdown is in the tree-traversal code. I'm seeing millions of isinstance calls from that, which can likely be optimized substantially.
array._array_interface_['data][0]
My testing in IPython with timeit says that the above statement is almost 3x faster than:
array.ctypes.data