handlerstats

Overview ¶

Command handlerstats reports how many times each registered handler fired.

Throughput here tracks the number of crossings into Go rather than the size of the document, so the number that explains a slow rewrite is how often each handler ran. The library reports nothing about that, and it cannot be recovered afterwards: an Option is opaque once built, so there is nothing to wrap and nothing to ask.

What can be done is to wrap the function before the Option is built, which is what this package does - one constructor per handler kind, each returning the Option the library would have returned and counting on the way through.

Three things it measures that are easy to guess wrong.

A text handler fires per chunk, not per text node, and the last chunk of every node is usually empty. So a page with one paragraph can report three text calls, two of which carry nothing, and a handler that does work per call does it on empty strings.

An element handler fires per start tag, so a selector that matches a common element is the cost of the rewrite whatever the handler does. Comparing calls against the element count says whether a selector is doing any narrowing.

An end-tag handler is registered from inside an element handler, so it cannot be wrapped from out here. Route it through Counter.EndTag and it is counted; call e.OnEndTag directly and it is not. That is a limitation of instrumenting from outside, and it is reported rather than hidden: the report says how many end-tag handlers were registered through this package.