hi, On Thu, Mar 4, 2021 at 3:30 PM Derick Rethans <der...@php.net> wrote:
> Hi, > > I saw the PRs coming in, I'll reply inline: > > On Thu, 4 Mar 2021, Dmitry Stogov wrote: > > > > https://github.com/php/php-src/commit/b4e9b1846376f562e27a13572a137ec584c13f58 > > As Nikita already commented, this now seems to introduce flakeyness into > tests. > > > And created 3 pull request for timelib: > > > > https://github.com/derickr/timelib/pull/98 > > That looks reasonable. I'm currently working on implementing > https://github.com/derickr/timelib/issues/14 which will also touch that > code, so I'll look at it as part of that work. > > > https://github.com/derickr/timelib/pull/99 > > Is incorrect, the tzfile 5 man page says: > > Time zone designations should consist of at least three (3) and no > more > than six (6) ASCII characters from the set of alphanumerics > timelib (timezonedb.h and fallbackmap.h) doesn't have abbreviation longer than 5 characters, but has single char abbreviations. > > I am curious to as to why this routine was called so often though, as > looking for abbreviations isn't something that should have be be done > often. > Every time you parse a time zone name (including a date with timezone) you always (except for UTS and GMT) perform a linear search through all entries listed in timezonedb.h (1128 string comparisons + 1128*2 lowercasing + 1128*2 calls to strlen()), and only then take a look for timezone name, that may be already cached. > > > https://github.com/derickr/timelib/pull/100 > > This new routine is perhaps faster, but it is also extremely more > complex, with little comments. It's unlikely I would want to incorporate > it in its current form. > What comments do you like? We first guess the year dividing days to 365, then check if our guess is right (number of days from the start of the guessed year fits into this year), and then continue searching. This is like a binary search, but with base 365 and the rule to check the leap year. > > Please, verify and merge the timelib patches into PHP. > > Please, let me know if this will take time. > > It will certainly take time :-) > > > I fixed only the visible, most significant and obvious bottlenecks. > > It's possible to improve timelib more... > > I'm sure it is! The code is 17 years old by now! > yeah, this is the problem. Nobody likes to improve it. I'm interested only because it significantly affects PHP performance. Thanks. Dmitry. > > cheers, > Derick >
