Re: timelib inefficiency
Hi Derick,
I spent some time looking in the timelib implementation caused slowness in
the Symphony Demo app (https://github.com/symfony/demo)
I committed one patch into ext/date:
https://github.com/php/php-src/commit/b4e9b1846376f562e27a13572a137ec584c13f58
And created 3 pull request for timelib:
https://github.com/derickr/timelib/pull/98
https://github.com/derickr/timelib/pull/99
https://github.com/derickr/timelib/pull/100
These patches make 5% improvement on the Symphony Demo app (100 homepage
requests after warm up, according to callgrind, timezone "Europe/Moscow")
Please, verify and merge the timelib patches into PHP.
Please, let me know if this will take time.
I fixed only the visible, most significant and obvious bottlenecks.
It's possible to improve timelib more...
Thanks. Dmitry.
On Thu, Feb 25, 2021 at 3:21 PM Dmitry Stogov <dmitrystogov@gmail.com>
wrote:
> Hi Derick,
>
> Please take a look
>
>
> https://github.com/php/php-src/blob/51914610ab8bf75d87e5cdec15bd1b38de7907c5/ext/date/lib/parse_date.re#L684-L700
>
> This code is enormously inefficient. For a single abbr_search(), it calls
> timelib_strcasecmp() more than 1000 times (complete linear search in a huge
> almost ordered array, with repeatable and redundant lowercasing). 11 calls
> to abbr_search() per request in the Symfony Demo application (
> https://github.com/symfony/demo) eat 2% of
> overall CPU time.
>
> I see some other inefficient patterns in timelib. e.g. API design that
> leads to many useless heap allocations/deallocations; calloc() followed by
> memcpy(), etc
>
> Thanks. Dmitry.
>
Thread (5 messages)