Some views and tabs are extremely slow to open despite the objects (classes) being indexed and the indexes maintained.
Most out-of-the-box APM table configurations are tested and benchmarked against a certain amount of data to determine if the user experience (loading time) for the table is acceptable. However, because these table configurations often complex filtering and sorting, the query itself may be somewhat inefficient as the number of obejcts grows. This is usually helped by indexing the objects in the database but sometimes, even despite having good indexes the query is slow to return results. In cases such as these, it is recommended that the user run the APM Performance Monitor and then loading the slow loading views.
https://communities.bentley.com/products/assetwise/asset_performance_management/w/wiki/37235/apm-performance-monitor
The performance monitor will identify whether the query is slow.
1. In those cases, the administrator user should review the table configuration(s) to see what kind of filtering criteria and sorts are used. Filters using the condition "contains" and sorts on text strings will result in large impacts on performance. Try to reduce the reduce the complexity of the filter by eliminating unneeded filters, using the filter condition called "Is exactly" and applying sorts on value lists or numeric columns only. This should greatly improve the performance of configuration. The query speed issues are exaggerated for those table configurations that are linked to a hierarchy, such as the Inspection Management view > Indicators tab > by Asset Hierarchy page.
2. Any table configurations that take a long time to load can also be improved by putting in a date filter (on or after) which will limit the query to a smaller subset.
3. Slow returning queries that aren't needed often should never be used as the default configuration. The administrator should use an out-of-the-box unedited table configuration as the default or an administrator created configuration with limited data and complexity as the default configuration. This will greatly reduce the impact on most end users.
4. Reduce the number of unnecessary columns, especially hidden columns. Hidden columns are still fetch data when a query is run so hidden columns that are not used to filter or sort data should be removed. Hidden columns are often the result of copying other table configurations and tailoring the table to make it perfect for a particular user, these can very easily be optimized by eliminating the unneeded data.
5. The Search field in the upper right-corner of the table configuration. The Search is used to quickly find data within a table configuration. However, this search does not actually just look into the table results that are currently loaded in the view. The contents of the search are actually temporarily added to the query and the query run again on the database. For most simple table configurations this does not have a significant impact on performance. However, for complex table configurations invoking a search will add the "Contains" filter on all columns defined in the search:
For example, on this indicator table configuration, using the search will populate a "contains" filter on the Indicator name, Indicator type, Asset (number), Asset Name, Hierarchy location and Alarm Type columns. This may not seem like much but realize that this will reduce the speed of the query by at least 6 times because the "contains" filter is being applied on 6 times as many columns as is needed.
The best way to address this problem on Personal or Administrator level configurations is to either reduced the columns that are searchable. This is done column by column:
Note, for large table configurations, it may even be desired to turn-off searchability for that table configuration completely.
.