Hi,
Since we received a message on the users list about this, I made some comparisons between 2.6.0-pl2 and 2.5.4. I am quite surprised to see 2.5.4 being 3-4 times quicker in routine operations like cookie login, changing db, going into Structure page for a table, etc.
Removing all the js setTimeout does not improve the situation much. (Those could be eventualy made conditional to the Safari browser.)
So I am hunting to find what happened.... Stay tuned (or help me :) My goal is to restore 2.5.4 speed for 2.6.1 !
Marc
Hi Marc!
Since we received a message on the users list about this, I made some comparisons between 2.6.0-pl2 and 2.5.4. I am quite surprised to see 2.5.4 being 3-4 times quicker in routine operations like cookie login, changing db, going into Structure page for a table, etc.
Okay, I had that impression as well for quite some time. Nice to see someone verifying this.
I suppose the config import stuff and the DB layer, as well as some added regular expression magic may add up to the performance impacts.
I am working with xdebug on Serendipity (a blog tool) performance tuning, so I will try to make the same for phpMyAdmin as well :)
Regards, Garvin.
hI mARC1
Since we received a message on the users list about this, I made some comparisons between 2.6.0-pl2 and 2.5.4. I am quite surprised to see 2.5.4 being 3-4 times quicker in routine operations like cookie login, changing db, going into Structure page for a table, etc.
Did you compare some special URLs? I just ran xdebug over the left frame and found it spends quite a lot of time in fetching Bookmark information for every table (pma_querybookmarks()). That should maybe be optimised to always fetch all bookmarks of a database and cache the result in a PHP array.
Regards, Garvin.
Hi All!
So I am hunting to find what happened.... Stay tuned (or help me :) My goal is to restore 2.5.4 speed for 2.6.1 !
I at least fixed some PHP issues: The bookmark querying in left frame, the nesting reducement and some collation string caching.
So this finally speeds up my left frame generation; now on to other "slow" places - do you suspect performance bottlenecks in PHP functions, or in HTML/JavaScript functions?
Regards, Garvin.
Garvin Hicking a écrit :
Hi All!
So I am hunting to find what happened.... Stay tuned (or help me :) My goal is to restore 2.5.4 speed for 2.6.1 !
I at least fixed some PHP issues: The bookmark querying in left frame, the nesting reducement and some collation string caching.
So this finally speeds up my left frame generation; now on to other "slow" places - do you suspect performance bottlenecks in PHP functions, or in HTML/JavaScript functions?
Regards, Garvin.
Garvin,
left frame says: Undefined index: label in bookmark.lib.php line 146.
I am currently setting my system to do some profiling with DBG. Did you try to remove the js setTimeout() to see the difference? They could probably made conditional to Safari only.
Apart from that, I am not suspecting anything in particular, that's why I want to do some profiling.
Marc
Hi Marc!
left frame says: Undefined index: label in bookmark.lib.php line 146.
I'm sorry, I didn't catch the case of an undefined $result. Just fixed it in CVS.
I am currently setting my system to do some profiling with DBG. Did you try to remove the js setTimeout() to see the difference? They could probably made conditional to Safari only.
No, I only investigated PHP internal issues on left.php and tbl_properties_structure.php. Because personally I did not experience speed decrease in the browser itself, only in page delievery times.
And I advise you to not use DBG, because it's quite outdated. I can only suggest xdebug 2 (beta, but mostly working - www.xdebug.org) and kcachegrind (KDE). The other options is to use APD (pecl.php.net). Both can be installed using the PEAR installer, and APD generates usable profiling data from the shell, but no graphical interface like xdebug+kcachegrind.
Apart from that, I am not suspecting anything in particular, that's why I want to do some profiling.
Okay; for me the left frame was the one always causing trouble, and the commit fixed things for me; the right frame was always "fast enough" for me ;)
Regards, Garvin.
Garvin Hicking a écrit :
Hi Marc!
left frame says: Undefined index: label in bookmark.lib.php line 146.
I'm sorry, I didn't catch the case of an undefined $result. Just fixed it in CVS.
I still had a problem. I just replaced a fetch_row by a fetch_assoc and it works now. Need fetch_assoc because we are using the field names.
Marc
I am currently setting my system to do some profiling with DBG. Did you try to remove the js setTimeout() to see the difference? They could probably made conditional to Safari only.
No, I only investigated PHP internal issues on left.php and tbl_properties_structure.php. Because personally I did not experience speed decrease in the browser itself, only in page delievery times.
And I advise you to not use DBG, because it's quite outdated. I can only suggest xdebug 2 (beta, but mostly working - www.xdebug.org) and kcachegrind (KDE). The other options is to use APD (pecl.php.net). Both can be installed using the PEAR installer, and APD generates usable profiling data from the shell, but no graphical interface like xdebug+kcachegrind.
Ok, I will have a look at those, thanks.
Marc
Apart from that, I am not suspecting anything in particular, that's why I want to do some profiling.
Okay; for me the left frame was the one always causing trouble, and the commit fixed things for me; the right frame was always "fast enough" for me ;)
Regards, Garvin.
-
Garvin Hicking -
Marc Delisle