Extension performance strategies
Creo Elements/Direct Model Manager has significantly improved performance for structurally-complex models accessed over a Wide Area Network (WAN). Most of the performance improvement comes from minimizing the number of database queries, especially during interactive and load/store actions.
This paper includes the best practices for minimizing database queries used by the Creo Elements/Direct Model Manager R&D engineers. By following these practices in your extensions you will avoid degrading Creo Elements/Direct Model Manager's performance for your users.
Characterize performance before and after extension
One key to avoiding performance degradation is to identify and address any regressions while they are still new. Creo Elements/Direct Model Manager includes a WANproxy tool so you can monitor database queries.
WANproxy monitors the communication between Creo Elements/Direct Model Manager and the database server, and prints out each query as it is being sent to the database. Count the number of queries before and after creating your extension to ensure that you haven't added any more queries than necessary. Using fewer queries is always better in a WAN environment and usually better on a local network.
To use WANproxy, set wanproxy.enabled to true in dev.properties (in the extension build tools). To simulate performance over a WAN, set wanproxy.latency to on.
Avoid database queries in Action menu isEnabled() and setDbObjects() functions
Action menus are used to perform actions on the different items in the Creo Elements/Direct Model Manager Workspace. You may add functions to the existing Creo Elements/Direct Model Manager action menus, and even create your own section with custom functions.
The isEnabled() function is called each time the user expands the action menu. The function returns true or false, depending on whether the menu item should be enabled or grayed out. Inserting a query in this function impacts interactive performance for all users, even ones not using your extension. It is best to just return "true" and delay executing a database query until/unless the user selects the menu item.
The setDbObjects() function...
When the user selects the menu item, its actionPerformed (ActionEvent e) function is called. By putting the database query in this function, only users of the extension must wait for the query. This approach also improves usability because your code can provide an informative message if the action cannot be performed, rather than just graying out the command name.
See the Action menu extension lab for more information on customizing Creo Elements/Direct Model Manager's action menus.
Use BigQuery to get many elements
BigQuery is a utility class that lets you construct a query to return many elements. The class automatically splits large queries into multiple queries and then unions the results, so you don't need to worry about whether the size of the query string will exceed either Creo Elements/Direct Manager Server or Oracle limits.
See the Javadoc in osm.biz.BigQuery for more information on using this class.
Use pseudo objects instead of opening elements directly
When you need to access information about an object you can open the element for read, open it for write, or use a pseudo object. Opening an element requires one or two database hits per element. Opening for write adds another database hit. Using pseudo objects is usually more efficient, but there are some limitations.
A pseudo object is an object that is created from a query result. When a query is executed, a table is created that contains one row for each database element that was returned from the query. This table is usually called an ltab (logical table). Creo Elements/Direct Model Manager can convert each row in the ltab into a Java business object that behaves almost exactly the same as an object opened for read. You can ask for the object's children or files (if it is a document), and permissions are maintained. The only thing you can't do is modify these objects.
Using pseudo objects is much faster because many elements are returned for a single query, as opposed to only a single element when the element is opened
Was this helpful?