[Phpmyadmin-devel] #4536 - master: import problem (PMA_String)

Chirayu Chiripal chirayu.chiripal at gmail.com
Thu Sep 25 20:08:00 CEST 2014

On Thu, Sep 25, 2014 at 12:17 AM, Hugues Peccatte <hugues.peccatte at gmail.com
> wrote:

> 2014-09-24 14:42 GMT+02:00 Chirayu Chiripal <chirayu.chiripal at 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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20140925/dfd9dc72/attachment.html>

More information about the Developers mailing list