As with any large modelling system, there are a number of factors that may affect performance. Below are a few guidelines we recommend that SW Architect users follow to ensure system performance is at its best.


Methods That can Affect Performance

The following methods are executed by the server, and can potentially affect system performance. You should only use one after verifying that it does not compromise the server operation and performance. Also, since these methods jump out of context, they should never be used when the result is assumed to be under configuration management. They should, for example, never be used in a Document script (/back:: vs Context:/back::).

  • Axis: back-to-part (Path Language)
  • Axis: back (Path language). See /back:: vs Context:/back:: for how to use Context:/back:: instead.
  • Axis: refobj-back-to-part (Path Language)
  • ForEachItemReference (SystemWeaver Script Language)


Even small changes to view definitions can make a difference for performance. If you find that a view is loading extremely slow, contact support@systemweaver.com to see if it can be easily optimized.


Minimize Viewed Parts in Default View Setting

Give extra thought to which parts need to be "turned on" (set to display) in the system's Default structure tree view setting(s) since SystemWeaver caches data to the client memory for all parts that are "turned on" in the tree. Minimizing viewed parts increases performance for users. And, they can always chose to add parts to the view on-the-fly if needed, or open a sub-model in a new tab.



Schedule Heavy Write Operations for Off-Peak Hours

System users have a lot to gain if heavy write (e.g., imports, etc.) operations, such as the scripted creation or modification of tens of thousands of items, e.g., test results, are scheduled for off-peak hours or outside of regular office hours. The reason being that client users working with related data may then search or pull up a structure that includes the new data and it will need to be read from the server and cached to their client, putting additional load on the server. See our Guidelines for API Usage for recommendations with regards to API usage.


Use of Structural Parts for Nodes

The use of Structural part types rather than Simple part types should be limited to those part structures when it is necessary to create a unique part representation of each part in a specific part structure. This may be the case, for example, at the lower component level and is almost never the case at higher levels in an item structure. Structural part types create or add to a node structure and node structures can impact performance negatively for all system users, i.e., when structure part types are used, a parallel node structure exists which must be loaded along with the item structure. With overuse of structural parts, loading times can be excessive and cause performance issues for all system users. (Creating a New Part Type)