Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108870
MIME-Version: 1.0
References: <09dd1b84-ed33-a059-82f9-5efd179e69d6@gmx.de> <0233ec6d-267f-a5e4-b114-17b4c9bbff60@alec.pl>
In-Reply-To: <0233ec6d-267f-a5e4-b114-17b4c9bbff60@alec.pl>
Date: Thu, 5 Mar 2020 14:33:28 +0000
Message-ID: <CALKiJKogO8=3jX=rA+PL6Xsag2DLT_PSijEwtX-XatrE00ZVrQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000049911b05a01c6cb2"
Subject: Re: [PHP-DEV] iconv vs. mbstring
From: rowan.collins@gmail.com (Rowan Tommins)

--00000000000049911b05a01c6cb2
Content-Type: text/plain; charset="UTF-8"

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/Roundcube/rcube_mime.php#L589
>
>

Either I misread, or you did: I thought that's exactly what Christoph was
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.


Regards,
-- 
Rowan Tommins
[IMSoP]

--00000000000049911b05a01c6cb2--