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

Hugues Peccatte hugues.peccatte at gmail.com
Fri Sep 26 23:35:04 CEST 2014


2014-09-26 6:29 GMT+02:00 Marc Delisle <marc at infomarc.info>:

> Le 2014-09-25 16:16, Hugues Peccatte a écrit :
> > 2014-09-25 22:02 GMT+02:00 Marc Delisle <marc at infomarc.info
> > <mailto:marc at infomarc.info>>:
> >
> >     Hugues Peccatte a écrit :
> >     > 2014-09-25 20:08 GMT+02:00 Chirayu Chiripal
> >     <chirayu.chiripal at gmail.com <mailto:chirayu.chiripal at gmail.com>>:
> >     >
> >     >>
> >     >> On Thu, Sep 25, 2014 at 12:17 AM, Hugues Peccatte <
> >     >> hugues.peccatte at gmail.com <mailto:hugues.peccatte at gmail.com>>
> wrote:
> >     >>
> >     >>> 2014-09-24 14:42 GMT+02:00 Chirayu Chiripal
> >     <chirayu.chiripal at gmail.com <mailto: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?
> >
> >
> > 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)) {
>
> --
> Marc Delisle | phpMyAdmin


Hi,

I'll see how to add a comment. PHPCS will curse us for too long lines. :)

I just found a limit to this method: the tests.
If mb_* functions exist, we won't be able to create our mb_* functions and
so to test it.

Even if there is this issue, I'm currently working on this new "pattern".

Hugues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20140926/ed0fe9eb/attachment.html>


More information about the Developers mailing list