On 06/10/2011 09:17 PM, Gerrit Voß wrote: > In general generic field handling (getField/editField by name or id) > might be slower as they are without rtt in 2.x, so the dynamic type > information had to be externalized and run through and an intermediate > handler.
Hi Gerrit, Yes, I noticed that generic field access pays a penalty by going through a non-inline virtual function in 2.0. I worked around this by caching the Field* and EditFieldHandlePtr returned by editField(). This allows me to get and set the field value quickly, however when setting, it will not call editSField or editMField to trigger the changed() function of the FieldContainer. On the list from a couple years ago, I found someone else with a similar issue, and the recommended solution is to simply make edit[SM]Field() public in FieldContainer. For now, I have done this in my local OpenSG source, but it would be nice to have a cleaner solution. Generic field access is a good feature of OpenSG but without inline speed it can only be used occasionally. But a separate issue is that ChangeList tracking and applying seems to be slower. With 1.8, it was a performance benefit for my application to use a separate update thread with a separate aspect. However with 2.0, the overhead of syncing the two aspects outweighs the benefit of updating in parallel, so I've had to disable the update thread. But in a cluster configuration I can't avoid this overhead. That said, recent revisions of ChangeList code is much improved, but I'm still not seeing 1.8 speeds. I still haven't quite figured out what is going on, and I'm not clear how much is the update thread ChangeList tracking being slower or if the apply()/clear() in the render thread is slower, or some of both. Thanks for your help, -Michael ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
