Re: speed up unicode normalization quick check

Mark Dilger <mark.dilger@enterprisedb.com>

From: Mark Dilger <mark.dilger@enterprisedb.com>
To: John Naylor <john.naylor@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-05-28T21:59:52Z
Lists: pgsql-hackers

> On May 21, 2020, at 12:12 AM, John Naylor <john.naylor@2ndquadrant.com> wrote:
> 
> Hi,
> 
> Attached is a patch to use perfect hashing to speed up Unicode
> normalization quick check.
> 
> 0001 changes the set of multipliers attempted when generating the hash
> function. The set in HEAD works for the current set of NFC codepoints,
> but not for the other types. Also, the updated multipliers now all
> compile to shift-and-add on most platform/compiler combinations
> available on godbolt.org (earlier experiments found in [1]). The
> existing keyword lists are fine with the new set, and don't seem to be
> very picky in general. As a test, it also successfully finds a
> function for the OS "words" file, the "D" sets of codepoints, and for
> sets of the first n built-in OIDs, where n > 5.

Prior to this patch, src/tools/gen_keywordlist.pl is the only script that uses PerfectHash.  Your patch adds a second.  I'm not convinced that modifying the PerfectHash code directly each time a new caller needs different multipliers is the right way to go. Could you instead make them arguments such that gen_keywordlist.pl, generate-unicode_combining_table.pl, and future callers can pass in the numbers they want?  Or is there some advantage to having it this way?

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






Commits

  1. Review format of code generated by PerfectHash.pm

  2. Fix compilation warning in unicode_norm.c

  3. Use perfect hash for NFC and NFKC Unicode Normalization quick check

  4. Improve set of candidate multipliers for perfect hash function generation

  5. Further improve pgindent's list of file exclusions.