This section provides further reference information on some of Clinic Flame's advanced features.
Clinic Flame by default hides various initializaton functions. Filtering out these frames reduces generally redundant initialization noise.
An option in the "Advanced" section of the Options Menu allows these to be shown.
When shown, Init blocks are presented like all other blocks, and will be shown or hidden according to the options selected in "Visibility by code area". The only differences is that when shown in the Info Panel, the context section on the right states "In initialization process".
By default, Clinic Flame merges all Optimized and Unoptimized functions, and represents them as single blocks. It also merges all inlinable functions in to the calling functions that they are later inlined into. This creates a simplified graph where stacks only diverge based code logic.
Unticking "Merge" in the "Advanced" section of the Options Menu separates Optimized and Unoptimized functions, showing them as seperate blocks and seperate stacks.
This is the unmerged view of the flamegraph we created for
Optimizing A Hot Function.
app.get (among others) forks into two stacks. One is the
original unoptimized function, the other is the optimized version.
With "Merge" unticked, there is another way to see which blocks are Optimized or Unoptimized. Another option, "Show optimization status", becomes available when "Merge" is unticked. If this is ticked, the text and outline colours of blocks are changed, along with the key at the bottom right of the flamegraph, to show:
Inlinable functions can be found by typing "inlinable" into the search box while "Merge" is unticked.
For example, in the above flamegraph (the one we generated while
Optimizing A Hot Function),
we can see more easily that
app.get forks into an optimized and unoptimized branch, and in
the optimized branch,
payload (selected) is flagged as "Inlinable".
This is why, when we looked at that flamegraph in the default merged view, it
was absent. It was inlined into its parent function, the optimized version
This often adds a significant amount of complexity to the flamegraph, much of which may not be wanted. Flame therefore allows users to expand the V8 options and filter specific types of V8 function:
This would include any native prototype methods (
Array.prototype.join for instance),
and any functions that aren't publicly exposed but are used internally by V8
InnerArrayJoin for instance).
In addition, evaluated functions (either code run with
eval or created with
will also appear as native frames, with the file path shown as
These are C++ frames pertaining to the runtime operations of V8's implementation
Tags can include
These are C++ frames that are called by the V8 layer, not including C++ frames that may be called in Node, Libuv or third party modules.
These frames can include the tags
RegExp stands for Regular Expressions. These are also captured as "frames". In this case the regular expression notation fills in as the "function name" portion of the block label. This can be useful in identifying slow regular expressions (in particular exponential time regular expressions).
These will have the tag