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

[Madhura Jayaratne]

On Wed, Sep 24, 2014 at 5:35 PM, Marc Delisle <marc at infomarc.info> wrote:

> Chirayu Chiripal a écrit :
> > Hi,
> >
> > On Wed, Sep 24, 2014 at 5:13 PM, Marc Delisle <marc at infomarc.info>
> wrote:
> >
> >> Hugues Peccatte a écrit :
> >>> 2014-09-23 20:04 GMT+02:00 Marc Delisle <marc at infomarc.info>:
> >>>
> >>>> Hugues Peccatte a écrit :
> >>>>> 2014-09-23 16:23 GMT+02:00 Marc Delisle <marc at infomarc.info>:
> >>>>>
> >>>>> That's it. Instead of using $pmaString->strlen or strlen, we could
> >>>> imagine
> >>>>> to use pmaStrlen and this function would call strlen or mb_strlen if
> >> mb_*
> >>>>> functions exist.
> >>>>> Another way could be to overwrite strlen with mb_strlen, but we
> >> wouldn't
> >>>> be
> >>>>> able to use the original strlen if needed. So I think that we should
> >>>> define
> >>>>> new functions.
> >>>> What I don't like is that we would have two different syntaxes to call
> >>>> string functions. We would need comments in the calling code to
> explain
> >>>> why we are using a way and not another way.
> >>>>
> >>>>> I'll try to do a mass replacement and check if the execution time is
> >>>> better.
> >>>>> Hugues.
> >>>> --
> >>>> Marc Delisle (phpMyAdmin)
> >>>>
> >>> If by "two ways", you think about PMA_String and pmaStr* functions,
> there
> >>> should be a misunderstanding. I don't want to keep PMA_String (at
> least,
> >>> not for string functions), I'd like to migrate it into functions.
> Here, I
> >>> kept it not to break anything, just to check performance.
> >>> If you think about pmaStr* functions and standard PHP functions, I
> don't
> >>> think this is a real issue, because we use PMA string object almost
> >>> everywhere today, so it would be replaced by function calls.
> >>>
> >>> Hugues.
> >> I believe it's a good idea to use just functions, but other developers
> >> might think otherwise.
> >>
> >
> > In that case, how will function decide whether to use mb_* function or
> > simple one? What if we use static methods?
>
> In the current implementation, the mb_* functions are preferred; so we
> would use the same priority, to define functions like PMA_substr().
>
>
For what it's worth I did some profiling of the import functionality and
here is what I observed.

If we consider the substring functionality

Using the native functions wrapped in OOP function calls,
php::substr took 0.34 micro secs on average (2.7ms for 8308 calls)
PMA_StringNative->substr took 13.26 micro secs on average (110ms for 8295
calls)
PMS_String->substr took 28.93 micro secs on average (244ms for 8294 calls)

Using the mb functions wrapped in OOP function calls,
php::mb_substr took 22 micro secs on average (220ms for 9700 calls)
PMA_StringMB->substr took 120.54 micro secs on average (1170ms for 9706
calls)
PMS_String->substr took 115.50 micro secs on average (958ms for 8294 calls)

So it seems like both factors (using mb functions as well as object
orientation) are responsible for the slowness.

See the attached screenshots too.

-- 
Thanks and Regards,

Madhura Jayaratne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20140924/af5942f6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MBString.png
Type: image/png
Size: 25019 bytes
Desc: not available
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20140924/af5942f6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NativeString.png
Type: image/png
Size: 31944 bytes
Desc: not available
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20140924/af5942f6/attachment-0001.png>