hadrieng2 / crofiler Goto Github PK

The v2 binary release was botched by axodotdev/cargo-dist#362 . Once an updated cargo-dist is available, switch to that, delete all the tags, and retry.

Rust 1.65 stabilizes the std Backtrace type, which means that this project will soon be able to do with one less build dependency. Let's switch to it once that release is old enough to be featured in, say, the ubuntu repos.

Will allow me to drop the once_cell and atty dependencies.

Crofiler expends most of its complexity budget on the Hard Problem of parsing and simplifying C++ entity names with unknown source file context. We probably don't have enough developer brain time to additionally produce a higher-quality profile visualization along the lines of what Firefox Profiler does for perf.

But could we have a third crofiler visualization frontend that just emits some data file that Firefox Profiler can consume, and offload all advanced visualization concerns to Firefox Profiler?

The main unknown to be investigated is whether Firefox Profiler supports, or can be made to support, the simplified/full entity name dichotomy that is the soul of crofiler. And if not, whether we're okay with emitting only simplified entity names.

In practice, the most common way to resolve template bloat in Acts has been to outsource some of it to a separate source file. One standard way to do it in C++ is explicit instantiations + extern template. Could crofiler automatically generate some of this boilerplate?

Cargo workspaces have this cool feature where you can specify all your dependencies in one place and then the versions remain in sync for free across inner packages.

It worked well in another project, I should try it here too.

Right now, C++ entity name simplification works as follows:

• Treat the entity name as an AST-like tree
• Have a way to do a depth-first walk of the tree that displays nodes, which truncates at a certain AST depth where the corresponding tree node is replaced by an ellipsis ….
• Repeat render at increasing depth until we go past the terminal columns budget, take previous depth.

This algorithm works well enough to offer the basic desired functionality, but has a number of known issues:

• Duplicated work. When we go to depth n+1, we repeat the rendering work we did for depth n, which itself repeats the rendering work we did for depth n-1. Furthermore, we don't leverage the node interning work that the parser carried out to deduplicate rendering work across similar AST nodes. This makes rendering of lots of entity names needlessly inefficient, which so far has not been a priority to optimize because last time I checked crofiler was mostly parsing-bound.
• Does not fully leverage available horizontal space. Sometimes, we could render some AST nodes at depth n+1, but we don't because rendering all AST nodes at that depth would blow our terminal columns budget.
• Does not priorize AST nodes. For example, entity paths through namespaces can be quite important for the reader trying to identify what type we are talking about, compared to other information like the exact set of template parameters that is passed to a generic function or type. More subtly, repeating the same information multiple times is not making efficient use of our terminal columns budget, so if a certain type has appeared once in an entity name, we may want to summarize its display more the second and third times it appears in the same entity name.
• Does nothing to avoid ambiguities. The single most important caveat to simplifying entity names is that it can make two slightly different entity names look the same, and it would be great if the display algorithm was tuned to favor keeping simplified names unambiguous if at all possible.

I'd like to try something along the lines of the following alternative algorithm instead:

• Pre-render all entity names to be displayed at present time, leveraging AST node interning for work deduplication + some sort of span markers to tell which parts of the rendered name correspond to which interned AST nodes.
• Keep simplified entity names sorted by decreasing terminal columns using something like a BinaryHeap.
• As long as the longest entity name uses too many terminal columns, try to simplify it.
  • Go through all top-level nodes, sort them by decreasing terminal column budget and try to simplify each of them in turn.
  • For each simplified display, compare it to all other displays in flight to see if it is now ambiguous with another existing display. If so, reject the simplification in this first pass (we'll do it only if we have to).
  • If we don't manage to find a node to simplify at the currrent depth, try at the next depth, and so on until we reach the leaf depth.
  • If we reached all AST leaves without simplifying the name enough, then start a more aggressive simplification pass where we accept ambiguity and thus simplification always succeeds.
• Once the entity name's display gets short enough, put it back into the list, and somehow avoid re-doing the same work as I move to the next-longest entity name which may have AST nodes in common with previously processed entity names.
• If the basic approach can be proven to work, gradually make it more sophisticated to incorporate the other concerns mentioned above.

I expect this to be a rather costly feature development, so it should only be done if this project starts to get more traction.

In addition to the simplified entity name displays in the symbol list, in TUI mode, crofiler provides a full display in the lower half of the screen. It would be great if this full display were pretty-printed with proper attention to the compromise between keeping things readable and not using too much vertical space.