On Wed, Sep 24, 2014 at 5:54 PM, Madhura Jayaratne madhura.cj@gmail.com wrote:
On Wed, Sep 24, 2014 at 5:35 PM, Marc Delisle marc@infomarc.info wrote:
Chirayu Chiripal a écrit :
Hi,
On Wed, Sep 24, 2014 at 5:13 PM, Marc Delisle marc@infomarc.info
wrote:
Hugues Peccatte a écrit :
2014-09-23 20:04 GMT+02:00 Marc Delisle marc@infomarc.info:
Hugues Peccatte a écrit : > 2014-09-23 16:23 GMT+02:00 Marc Delisle marc@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