[RFC] Performance and scalabity of Debug bar(s) (and sliders) for SQL queries #21131
Description
[J3.8.10]
The implementation of the debug screen for SQL queries,
has a horrible performance, it does not scale
it is O(N*N) (or something like this) where N is the number of SQL queries
we are creating N debug bars .... 1 for every SQL
(and then also N JS sliders for the information of every query)
thus having a total N*N links e.g. if you have a page with 300 queries e.g. because of Joomla Core or 3rd party extension messing up and having a very fast query inside a loop (0.5 seconds can easily go unnoticed e.g. like when in the past Joomla Core had 1 SQL queries per category in article form!) then you will get 90,000 links created
and then add to it the JS that attaches event to every debug bar
and other CORE JS
e.g. this PR #21126 tries to reduce the JS that runs on the page by replacing the JS sliders with CSS
plus we have unknown 3rd party JS searching / manipulating the DOM that has the 90,000 links, plus the contents of the sliders ...
why create N debug bars ?
why create N sliders ? (PR #21126, solves this partly)
and not 1 debug bar with sticky positioning and some smart UI ? (that will continue to display text of all SQL queries, etc)
and also why not have all sliders empty on page load ?
no need for browser to parse their HTML. avoid 3rd JS party JS slow down
just populate the sliders on click from 2 or 3 JS arrays
it is not like we want the HTML contents of the sliders to be present in the page so that search engines will index it ...