profiling_qweb_view

When you enable profiling in Odoo, the server records how long each part of a QWeb template took and how many queries it triggered, and stores the result as JSON on an ir.profile record. This widget turns that JSON back into something a developer can read.

It loads the Ace library on startup, renders the template source in QWeb mode with the editor set to read-only, then walks the rendered DOM and attaches two kinds of annotation: a per-line summary in the gutter, and a hover panel on individual QWeb directives showing the time and queries attributed to that directive.

It also fetches the names of every view in the profile so the selector at the top can list them with their totals, letting you jump between templates without leaving the record.

This is the screen you end up on when a page is slow and nobody can say why. Rather than guessing which part of a template is expensive, it shows you the line.

The value for a business is indirect but real: performance complaints usually arrive as the system is slow, which is unactionable. A profile turns that into a specific template, a specific directive and a query count, which is a fixable ticket. If your team reports slowness and your partner cannot tell you where the time goes, this is the tool they are not using.

The only standard use, on the profiling record's result field:

<field name="result" widget="profiling_qweb_view"/>

The field must hold the JSON structure the profiler produces. The widget parses it on setup and normalizes the xpaths inside it before rendering, so an arbitrary JSON blob will not work here.

Two details change how you read this screen.

First, a collapsed line aggregates its children. When the widget builds the gutter summary it checks whether the Ace row is folded:

const closed = !!row.querySelector(".ace_closed");
...
(closed ? line.xpath.startsWith(xpath) : line.xpath === xpath)

A folded element reports the total for its whole subtree. An expanded one reports only itself. So the same line can honestly show two very different numbers depending on whether you have collapsed it, and folding a block is the fastest way to ask what does this whole section cost.

Second, the widget rewrites the xpaths it is given before using them:

line.xpath = line.xpath.replace(/([^\]])\//g, "$1[1]/").replace(/([^\]])$/g, "$1[1]");

This inserts an explicit [1] index wherever the server left one implicit, so that the profiler's paths line up with the paths the widget computes while walking the editor's DOM. It is why a path you copy from this screen may not match one you read in a server log verbatim.

One practical caution: the annotation pass re-runs on every Ace render, including on scroll, and is debounced by 100 milliseconds. On a large template the screen settles rather than appearing instantly. That is the widget working, not hanging.

No change. Diffing the registration between the 19.0 and 20.0 branches shows the same single-key descriptor and no new options.

The component itself is rewritten internally for OWL 3, like every widget in Odoo 20, but nothing about the screen or how it is applied changes.