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