2014-09-21 16:30 GMT+02:00 Hugues Peccatte <hugues.peccatte@gmail.com>:
2014-09-21 12:20 GMT+02:00 Marc Delisle <marc@infomarc.info>:
Le 2014-09-20 21:05, Marc Delisle a écrit :
> Hi Hugues,
>
> I have not looked deep into this logic, so it seems that you've become
> the expert here in these matters.
>
> Taking into account that the current master is not acceptable for a
> 4.3.0-alpha release, I see a few choices:
>
> - remove the mb modifications from the import logic

This one would be the easiest.

This one isn't possible. Even with undoing all modifications in this function, the execution is too long.
 
 
>
> - remove the current parser from the import logic, therefore removing
> support for things like a custom delimiter and probably other things
> (import of compressed files?)

The issue isn't about compressed files. I tried to import the SQL into your zip file: it was too long…
 
>
> - delay 4.3.0 until we find the correct solution with mb 

I don't know the delay to find a solution, so not sure that would be enough.
 

We could also add another (!) custom option in the import dialog:
multi-byte or not.

This might be possible… I'll do some tests about choosing the PMA_String* to use.

So, this is not possible either.
 
 

The multi-byte way is the more correct one for importing files with
multi-byte characters, but simply does not work for big files (10 to 15
times slower). So by default, the option could be set to not use the
multi-byte way.

A user with a big multi-byte file would have a problem, unless she is
allowed to set the PHP execution time limit to huge values (which not
many sysadmins will allow unless they want their shared server to
perform badly).

--
Marc Delisle | phpMyAdmin 

Thanks for your feedback. 

Hugues. 

I still try to find the greedy part of the script.

Hugues.