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 <dmitrysto...@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. >
