Hi Paul, On 1/18/07, Paul Melis <[EMAIL PROTECTED]> wrote:
Introspection is very powerful, but even for languages that provide good capabilities in this area, like java or c#, nobody is building wrappers that use introspection AT RUNTIME. This adds a huge overhead, which is not attractive as directly wrapping low-level code in a language like Python already adds a layer for native<->Python data conversion, delegation of method calls, etc. which impacts performance. A more sensable approach in my opinion is to use osgIntrospection to generate wrapper code in a way that tools like SWIG do it. This kind of code directly wraps C++ classes and tries to keep the overhead to a minimum. No introspection calls would have to be done at runtime, the capabilities would simply be used to generate code.
I've thought about this route as well, suggesting it previously on the C# thread, and perhaps at other times to. For creating a osgIntrosepction binary reader/writer it would be most efficient to go this route. As for performance, it all depends on how much you stress the the bridge between the python/lua/etc side and the C++. If you don't do a huge number of low level ops per second then there will be little stress and no need to go round trying to optimize things. If you are primarily using the phyton/lua to create the scene graph again this is unlikely to be a great bottleneck as its a one time op. If you do need real performance you can always drop back into C++. Having a lighter weight bridge between Python/Lua might delay the time when you need to drop back into C++, so might promote keeping in these languages for a higher percentage of your program. However, what you really need to do is benchmark to see if the programs to see in osgIntrospection runtime wrapping is practical bottleneck, its still to early days to say in the case of osgPython and osgLua what areas are likely to be real issues. Perhaps one can mix and match a little, have a small proportion of highly tuned wrappers, and large portion of auto generated ones. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
