Le 2014-09-25 16:16, Hugues Peccatte a écrit :
2014-09-25 22:02 GMT+02:00 Marc Delisle <marc@infomarc.info mailto:marc@infomarc.info>:
Hugues Peccatte a écrit : > 2014-09-25 20:08 GMT+02:00 Chirayu Chiripal <chirayu.chiripal@gmail.com <mailto:chirayu.chiripal@gmail.com>>: > >> >> On Thu, Sep 25, 2014 at 12:17 AM, Hugues Peccatte < >> hugues.peccatte@gmail.com <mailto:hugues.peccatte@gmail.com>> wrote: >> >>> 2014-09-24 14:42 GMT+02:00 Chirayu Chiripal <chirayu.chiripal@gmail.com <mailto:chirayu.chiripal@gmail.com>>: >>>> >>>> I was just wondering what will be the effect if we make current methods >>>> as static in those classes? >>>> >>>> -- >>>> Regards, >>>> Chirayu Chiripal >>>> https://chirayuchiripal.wordpress.com/ >>>> >>> It's almost the same thing to use a static or a non-static function. This >>> is 2.5x slower than standard PHP function. >>> >>> See: >>> Time: 1.7506999969482 //standard PHP function >>> Time: 4.3722500801086 //object >>> Time: 4.3722498416901 //object with static function >>> Time: 3.6722099781036 //PMA function, even this one is 2x slower than >>> standard PHP function… >>> >> Are these tests performed on mb_* function or non mb_* one?I forgot to answer to this question… So the tests are with non mb_* functions.
>> >> One thing is clear from these results is that even wrapping a built in >> function in another function (wrapper function) has some significant >> overhead. And using OOP/Classes is like wrapping that wrapper function >> further into a another wrapper causing further slowness. So why not just >> use mb_* function directly everywhere? If we do this, then what to do in >> case mb_* functions are not available? Maybe we can just define a new mb_* >> function to use respective non mb_* function for it. For e.g. >> // Define a function like this >> function mb_strlen($str) { >> return strlen($str); >> } >> // or create an alias of strlen() as mb_strlen() (I heard this is possible >> in PHP 5.6+) >> >> By doing this, we can get speed advantage of built in mb_* function >> whenever it is available by avoiding any wrapper function or class. And in >> cases where it is not available, a wrapper function with standard non mb >> function can deliver equivalent performance as non mb function is >> inherently faster than its mb_* mod. >> >> >>> Hugues. >>> > Hi, > > This is a very good idea! > > Marc, you asked to create PMA_* string functions. Do you agree with the > Chirayu's proposal? So we won't have PMA_* functions, but only mb_* > functions. > > Hugues. I have not followed the latest test results in this thread. If it's true that using wrappers has a big cost, I am in favor but I fear that people reading the code do not realize that the mb_* function could be a wrapper. Not sure how to document this. -- Marc Delisle (phpMyAdmin)Using wrappers, the time could be doubled. So with his proposition, the wrappers would be created only when mb_* doesn't exist. If mb_* exist, we won't redefine it, but the execution would be slower because mb_* are slower. If mb_* don't exist, the non-mb_* functions would be wrapped, so will be a little bit longer than without wrap. And we would also be able to force the use of non-mb_* functions if needed.
As you said, the only thing that might be difficult, would be to document the fact that mb_* functions could be pMA functions. We should choose between clarity and "performance".
Performance should have priority, but maybe we can have both. I assume that the changes will be done automatically, so what about introducing a small PHP comment at the same time?
Something like this:
(before) if ($pmaString->strlen($db)) {
(after) if (/* overload? */ mb_strlen($db)) {