Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108872
To: Rowan Tommins <rowan.collins@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <09dd1b84-ed33-a059-82f9-5efd179e69d6@gmx.de>
 <0233ec6d-267f-a5e4-b114-17b4c9bbff60@alec.pl>
 <CALKiJKogO8=3jX=rA+PL6Xsag2DLT_PSijEwtX-XatrE00ZVrQ@mail.gmail.com>
Message-ID: <6c177180-e5cb-7446-4ab4-0250aa3cb16c@gmx.de>
Date: Thu, 5 Mar 2020 16:13:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <CALKiJKogO8=3jX=rA+PL6Xsag2DLT_PSijEwtX-XatrE00ZVrQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] iconv vs. mbstring
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 05.03.2020 at 15:33, Rowan Tommins wrote:

> On Thu, 5 Mar 2020 at 11:59, Aleksander Machniak <alec@alec.pl> wrote:
>

>> Also, I have a case in which iconv_* functions were much much slower
>> than mbstring. See wordwrap implementation in
>>
>> https://github.com/roundcube/roundcubemail/blob/master/program/lib/Roun=
dcube/rcube_mime.php#L589
>
> Either I misread, or you did: I thought that's exactly what Christoph wa=
s
> saying, that iconv_* functions will be slower because they basically do
> convert-process-unconvert rather than having implementations for each
> encoding. So mb_strlen will always be faster than iconv_strlen.
>
> iconv() vs mb_convert_encoding() doesn't have the same penalty. It seems
> quite plausible that a library dedicated to converting charsets would be
> more optimised for that job than a single function in a larger library
> mainly focussed on working with one charset at a time.

I should add that all my testing was done solely with a current libiconv
version (on Windows); I don't know how libc's ivonc() and other
implementations might perform.

=2D-
Christoph M. Becker