Debugging performance with Phoenix LiveDashboard

[ivanminutillo]

Following some interesting insights about potential performance issues found using LiveDashboard tools, esp. Orion and Flame on.
The functions are recorded during the loading of the Home feed

Bonfire.Common.Extend.maybe_extension_loaded!/1
Execution is pretty fast (99% under 9ms), but (If I understand the graph correctly) it is been called in a range of 160 - 260 times x second across a period of 55 secs (15:21:10 - 15:22:05)

Performance Graph:

Profiler:

zooming out :

My guess is that even if the time execution is very fast, the amount of time the function is called for such a consistent period of time may cause the instance to consistently slow down? Looking at the profiler graph, in first instance I tought that impressive repetition that is shown in the flame graph was caused by a recursive loop somewhere, but maybe it's just a consequence of how modular is bonfire and how modules from different extensions are linked together in a complex view such as the Feed view.

I'm not that good with the BEAM to say tough if this can likely be an issue or not? Feedback are very welcome :)

[mayel]

Just had a quick look, maybe_extension_loaded! is called whenever you do Config.get or Settings.get so the amount of times isn't necessarily alarming, though always good to double check, and probably the functions can be reduced/optimised a bit when we know how often they're used...

[ivanminutillo]

yeah maybe for foundational extensions (such as ui_social / ui_reactions / boundaries / etc) we can assume they're enabled? or we can cache the list of extensions loaded? because they are not likely to change that often and they are updated only via settings so updating the cache should be trivial enough?

[mayel]

we can assume they're enabled

I'd not do that, would loose flexibility and the ability to swap them out

we can cache the list of extensions loaded

seems to assume that elixir/erlang is not already caching or that they're slow, which we just need to measure

[ivanminutillo]

Adding the list of potential N+1 (from logs and honeycomb)

• bonfire_data_activity_pub_peered (possibly triggered by is_local?)
• pointers_pointer (possibly triggered by Boundaries.can?)

[mayel]

added some extra measuring of memory use and execution time during runtime...