You can investigate slow ViewModel data fetching by inspecting its QueryPlan and recording the QueryPlan activity in the debugger; this guide is for MDriven Designer developers diagnosing a slow view.

What to measure

Start with one reproducible user operation and one ViewModel. For example, measure the time from selecting an item in a seeker until its detail view is available. Repeat the same operation with representative data and, where relevant, with representative network latency.

A QueryPlan is MDriven's static analysis of the data a ViewModel will use. It is intended to fetch that data efficiently and avoid lazy fetches that can otherwise cause repeated server roundtrips.

Profiling workflow

1. Reproduce one slow operation. Record the ViewModel, the user action, the input size, and the observed delay. For example: select a project in a seeker that displays project details.
2. Inspect the ViewModel's static QueryPlan. The report is copied to the clipboard.
3. Review the report for the classes and relations the view needs at each hierarchy level. A view that reaches many classes and relations can require substantial data fetching.
4. Debug the ViewModel fetch.
5. Let the ViewModel fetch run and inspect the resulting log.
6. Compare the observed fetch activity with the QueryPlan report and the ViewModel expressions. Check whether a seeker selection or another change to a vCurrent variable causes data to be fetched below that point.
7. Change one cause at a time, then repeat the same operation with the same data. For example, reduce an unnecessarily broad input collection or correct an OCL expression that creates a large intermediate collection.

Read the QueryPlan log

The PMapper log shows QueryPlan execution stages. Use the stage names to relate the log to the part of the ViewModel being fetched.

For example, if selecting a seeker result triggers hierarchy processing followed by column processing, inspect the selected object's hierarchy and column expressions. QueryPlan subscribes to vCurrent variables for nesting levels, so a changed selection can initiate efficient fetching below the changed point.

Optimize the cause you found

Match the change to the evidence from the QueryPlan report and log.

• If the ViewModel reaches data that the user does not need for the operation, review its hierarchy, nesting, and expressions. Efficient ViewModel fetch and Delayed Fetch describe related fetch behavior.
• If an OCL expression creates a large intermediate result, change the expression rather than treating the delay as a fetch problem. For example, use foreach for repeated mutation when you do not need a returned collection; see Documentation:Collect very slow.
• If the view depends on derivations in attributes or associations, include those derivations in the investigation. Derivations can otherwise lead to lazy fetching as the UI is drawn.

Do not assume that delayed fetching removes the cost of an expression or data that the ViewModel eventually needs. Re-run the same scenario after every change and keep the before-and-after observation with the ViewModel.

Scope and limits

This workflow inspects MDriven QueryPlan activity; it is not a database query execution-plan guide. The documented PMapper logging is specifically for QueryPlan entries, and multi-expression fetching is a feature of MDrivenServer; the XML persistence mapper does not use it.

See also

• Documentation:QueryPlan
• Documentation:Efficient ViewModel fetch
• Documentation:Delayed Fetch
• Documentation:Collect very slow