Re: speed up unicode normalization quick check - Mailing list pgsql-hackers

From John Naylor
Subject Re: speed up unicode normalization quick check
Date
Msg-id CAFBsxsGpmuEqd1RvZqMrVg6Q8g3j53XdLSc9EWDyoD2WSVdK9g@mail.gmail.com
Whole thread Raw
In response to Re: speed up unicode normalization quick check  (Michael Paquier <michael@paquier.xyz>)
Responses Re: speed up unicode normalization quick check
List pgsql-hackers


On Thu, Oct 8, 2020 at 2:48 AM Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Oct 07, 2020 at 03:18:44PM +0900, Michael Paquier wrote:
I looked at this one again today, and applied it.  I looked at what
MSVC compiler was able to do in terms of optimizationswith
shift-and-add for multipliers, and it is by far not as good as gcc or
clang, applying imul for basically all the primes we could use for the
perfect hash generation.

Thanks for picking this up! As I recall, godbolt.org also showed MSVC unable to do this optimization.
 
> I have tested 0002 and 0003, that had better be merged together at the
> end, and I can see performance improvements with MSVC and gcc similar
> to what is being reported upthread, with 20~30% gains for simple
> data sample using IS NFC/NFKC.  That's cool.

For these two, I have merged both together and did some adjustments as
per the attached.  Not many tweaks, mainly some more comments for the
unicode header files as the number of structures generated gets
higher. 

Looks fine overall, but one minor nit: I'm curious why you made a separate section in the pgindent exclusions. The style in that file seems to be one comment per category.
 
--
John Naylor 

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Next
From: Amit Kapila
Date:
Subject: Re: Resetting spilled txn statistics in pg_stat_replication