2014-09-24 14:42 GMT+02:00 Chirayu Chiripal <chirayu.chiripal@gmail.com>:

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:

In the current implementation, the mb_* functions are preferred; so we
would use the same priority, to define functions like PMA_substr().

Ok. I'll try to do this.

 

 

For what it's worth I did some profiling of the import functionality and here is what I observed.

It's worth it! 

 

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. 

Yes, we know than both makes the script slower. OOP can be avoided, but I don't think that we could avoid using mb functions. So this is our minimal constraint.

 

See the attached screenshots too.

I don't know this tool! What is it please? This seems to be very useful, at least for the benchmark I try to do currently.