Feature: Expose results for in game tools

[fulgenscode]

Would it be possible to expose the results as dynamic variables so it's possible to experiment with things like aggregation and charts in game? If there is a serious impact then perhaps the variables can be added after profiling is stopped. Maybe individual entries could have realtime variables enabled so they can be charted over time?

I want to experiment with different ways of aggregating and visualizing the things taking up performance so it's easier to decide which things might be worth spending time to investigate. For instance if there are 200 simple drivers they may be collectively taking up 50% of world performance but they will all be at the bottom of the list. The hierarchy view sort of helps with this but it doesn't separate flux performance from other things like components so it's hard to know if your object is heavy because of the drives or because of other components on it.

One of the reasons I bring this up is because I want to sort the metrics into bins which each have say 10% of world execution time. Then the 200 drivers would take up say 5 bins and when displayed it would be obvious that could be worth prioritizing. They could be colored by a hash of the slot name so that a lot of objects with the same name would stand out.

I thought about making this a request but I wasn't sure what I actually wanted so I thought it may be better to be able to experiment and determine what works best in practice.

[esnya]

Thanks for the detailed write‑up and the idea.

I’m hesitant to add this to the mod:

• Real‑time updates could consume excessive bandwidth and introduce non‑trivial runtime overhead.
• If results are exposed only after a capture ends, in‑world items that depend on those variables may not appear when they’re actually needed.

For context, this mod is in maintenance mode, and I’m not enthusiastic about adding new features. Because, FrooxEngine is already on .NET 9. I expect a more efficient, runtime‑embedded metrics counter to be integrated in the near future, which should be consumable via OpenTelemetry‑based tools.

If you need new metrics, please request them via the official issue tracker.

Workarounds today

In the hierarchy view, filter measurement stages in the mod settings (e.g., focus only on ProtoFluxContinuousUpdate).
Use the standard debug dialog to identify which stages are bottlenecks.

P.S.

Pull requests are welcome.