Performance Tips (XSISDK)

Table of contents


To help debug performance problems, such as a slow workgroup, set the environmental variable XSI_LOG_LOAD_TIME to the value "1".

When this environment variable is set, XSI logs extra messages during startup. The Plug-in Manager also logs additional messages whenever it is initialized or updated.

The information logged during startup looks something like this:

//Initialize Mental Ray: Elapsed time (ms): 19.87
//Load Command Definitions: Elapsed time (ms): 80.29
//Project List Initialization: Elapsed time (ms): 4.22
//Load Views and Shelfs: Elapsed time (ms): 2498.65
//Load Layouts: Elapsed time (ms): 222.94
//Loading custom location plug-ins: Elapsed time (ms): 0.19
//Loading User plug-ins: Elapsed time (ms): 205.80
//Loading User addon plug-ins: Elapsed time (ms): 6.29
//Loading Workgroup plug-ins: Elapsed time (ms): 403.70
//Loading Workgroup addon plug-ins: Elapsed time (ms): 791.36
//Loading Factory plug-ins: Elapsed time (ms): 1013.89
//Loading Factory addon plug-ins: Elapsed time (ms): 1209.82
//Loading setup plug-ins: Elapsed time (ms): 0.25
//Scan for Custom SPDLs: Elapsed time (ms): 987.57
//XSI Init: Elapsed time (s): 13.86

The information logged by the Plug-in Manager looks like this:

//Loading custom location plug-ins: Elapsed time (ms): 0.14
//Loading User plug-ins: Elapsed time (ms): 2.58
//Loading User addon plug-ins: Elapsed time (ms): 2.87
//Loading Workgroup plug-ins: Elapsed time (ms): 12.56
//Loading Workgroup addon plug-ins: Elapsed time (ms): 34.87
//Loading Factory plug-ins: Elapsed time (ms): 7.16
//Loading Factory addon plug-ins: Elapsed time (ms): 52.83
//Loading setup plug-ins: Elapsed time (ms): 0.08
//Scan for Custom SPDLs: Elapsed time (ms): 986.09
//Rebuild Plug-in Tree: Elapsed time (ms): 401.12

Slow Plug-in Manager Tree

The XSI v.5.0 plug-in manager includes a tree showing self-installed plug-ins and other files. If you find it too slow to redraw you can turn of the display of some file types. For example if you are not working on Relational Views then you can disable the display of those files in the Plug-in Manager Preferences.

This JScript will turn off all the optional elements that might impact the speed of the Plug-in Manager Tree.

// JScript
SetValue("preferences.plugin_manager.show_factory_in_tree", false, null);
SetValue("preferences.plugin_manager.show_pluginitems", false, null);
SetValue("preferences.plugin_manager.show_spdls", false, null);
SetValue("preferences.plugin_manager.show_toolbars", false, null);
SetValue("preferences.plugin_manager.show_views", false, null);

Debugging Operator Evaluation

XSI v.5.0 provides low-level tracing functionality for operator evaluations. It can be quite useful in debugging rig setup to find performance problems. To enable it, set this environmental variable:


Note: You have to restart XSI to see the environmental variable in action.

Example (from Simon Inwood): From this we can deduce that the computation inside the secondaryshapemarker took ~ 4ms (54.30355-50.33573) but about 50ms to pull its inputs. Your custom operators should take about the same amount of time 4-10ms. In some cases you can speed up custom operator by recompiling in C++; I've seen 10x increases especially with stuff that modified geometry or cluster properties. You don't alway see results from compiling in C++; for example I've ported constraint like operators from JScript to C++ and not really seen any difference.

(history log prefixes have been removed)
    secondaryshapemarker<15907>, BeginEval
     animationmarker<15906>, BeginEval
      shapemarker<15905>, BeginEval
       modelingmarker<15904>, BeginEval
        customop<4513>, BeginEval
        customop<4513>, EndEval, EvalTimeMs:37.85397
       modelingmarker<15904>, EndEval, EvalTimeMs:41.98550
      shapemarker<15905>, EndEval, EvalTimeMs:46.04496
     animationmarker<15906>, EndEval, EvalTimeMs:50.33573
    secondaryshapemarker<15907>, EndEval, EvalTimeMs:54.30355

A nice touch is that you can cut and paste the operator id ( customop<4513>) into the mcp select field and have it select the operator - speeds up locating it in the scene hierarchy.

Logging is slow

There is a certain cost to logging anything to the script history. A script that outputs hundreds of lines of text will slow down the execution of a script in a noticable fashion.

Many commands log each time they are executed, and certain operations, for example painting on a weight map, can produce huge command logs. Also if you write your script as a custom command it will not log each separate command call inside the command.

Object Model calls do not log, so they do not have this problem. An example logging optimization is to replace calls to SetValue() with equivalent Object Model calls.

For debugging information it is recommended that this be logged with the new siVerbose flag. That way a normal user will not see the debugging output, but a developer can enable the verbose mode preference and see this information (at the cost of a potentially slower execution).

Access to parameters

Parameters are accessed in the XSI SDK through the ProjectItem class. This class is the base for most of the SDK classes and allow writing generic and reusable code. While it always pay off to write generic code, it also comes with a performance cost when it comes down to parameter access. To optimize the performance we recommend to always get the parameters from their primary owner i.e the immediate parent of the parameters.

Consider the Camera object for instance which has several children objects where each have their own parameters. You can write some generic code like this to get the camera's X position:

	Application app;
	Model model = app.GetActiveSceneRoot();
	ProjectItem camera = model.GetChild(L"Camera");
	Parameter posx = camera.GetParameters().GetItem("posx");
	app.LogMessage( posx.GetValue().GetAsText() );

The call to camera.GetParameters() navigates the whole camera hierarchy and collects all the parameters nested under the camera including the primitive, camera display, kinematics, visibility, etc... It would be much more preferable to get the parameters directly from the camera's local KinematicState object instead which holds the posx parameter. Doing so, XSI will not navigate all camera children objects but only the kinematic property where posx is defined.

	Application app;
	Model model = app.GetActiveSceneRoot();
	Camera camera = model.GetChild(L"Camera");
	KinematicState ks = camera.GetKinematics().GetLocal();
	Parameter posx = ks.GetParameters().GetItem("posx");
	app.LogMessage( posx.GetValue().GetAsText() );

See also

This page was last modified 14:30, 21 Nov 2005.
This page has been accessed 18170 times.

© Copyright 2009 Autodesk Inc. All Rights Reserved. Privacy Policy | Legal Notices and Trademarks | Report Piracy