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

[Chirayu Chiripal]

On Wed, Sep 24, 2014 at 5:54 PM, Madhura Jayaratne <madhura.cj at gmail.com>
wrote:

>
>
> 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.
>

I was just wondering what will be the effect if we make current methods as
static in those classes?


>
> --
> Thanks and Regards,
>
> Madhura Jayaratne
>
>

-- 
Regards,
Chirayu Chiripal
https://chirayuchiripal.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20140924/93be7163/attachment.html>