More performance, speed first

[williamdes]

This issue focuses on tracking performance issues and improvements that can be made.

You can use xdebug or xhprof. Xhprof is just better. Here is how to use it.

xdebug config

xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=1
xdebug.profiler_append=1
xdebug.profiler_output_dir="/mnt/Dev/@phpmyadmin/theREALphpMyAdminREPO"
xdebug.profiler_output_nme="xdebug-profile.%t.%p"

xdebug.auto_trace=1
xdebug.trace_enable_trigger=1
xdebug.trace_options=1
xdebug.collect_params=4
xdebug.collect_return=0
xdebug.trace_format=0
xdebug.show_mem_delta=1
xdebug.trace_output_dir="/mnt/Dev/@phpmyadmin/theREALphpMyAdminREPO"
xdebug.trace_output_name="trace.%t.%p"

xdebug.file_link_format="xdebug://%f@%l"
xdebug.remote_log="/mnt/Dev/@phpmyadmin/theREALphpMyAdminREPO/xdebug.log"

Here we are talking about milliseconds. This is the point of this issue.

[williamdes]

@MauricioFauth the DI yaml parsing is very very complicated and uses a lot of operations.
I would want to change it to a format that does not need complex parsing
Do you agree ?

[MauricioFauth]

If you think it is a good improvement, go ahead. And if I remember correctly, this is the only place where we use the yaml dependency.

[williamdes]

I am working on it, kind of complicated because I need to write some php code to process the array but I will end up making it work

[MauricioFauth]

Isn't it easier to switch the file loader?

[williamdes]

The XML parsing is better than the yaml one but using a php array in a file should even better

[williamdes]

Done in #16007

[williamdes]

This patch did slow down the export by A LOT: e61b213

[williamdes]

Performance finding: calling PHP getters a LOT of times (example: 50000 times) is not worth it. Use a public class attribute instead (and add @readonly as a phpdoc).

[NKarasek]

Regarding good coding practice - and optimization. In looking through the PHPMyAdmin file 'move.js', I found many places where code developed a reference to an object using 'getElementById()'. While doing this once or twice is not a big deal, doing it within a loop (worse - multiple loops - perhaps looking at ALL of the columns for ALL of the tables available to Designer for example) is a big deal. To optimize this scenario, it would be considerably better to develop the necessary reference to the element (object), store that reference in a local var, and use the var in further calls to object attributes (for example, or adding/removing classes, css attributes, everything.)

I saw a bug report a few months ago that called out designer for glitching during the drag of a table through a designer page - a common enough scenario. I replicated the problem on my (admittedly old - read Sssllllooowww) Dell system and solved the problem by rewriting everything I could find in move.js that met the scenario above. I only addressed cases where calls to 'getElementById()' occurred more than two times in a row - the break-even point when computing Big 'O' (without delving into exactly how JQuery works its magic :-)

As a general rule - just my suggestion - but I would recommend that this type of optimization be a part of all 'best coding' practices - certainly with a project as deep and wide as PHPMyAdmin. I will be checking out other js files and templates to see if this concept can be used to advantage elsewhere.