Message-ID: <677cde50-6d64-474b-9ba8-bab380a111b3@gmail.com>
Date: Tue, 24 Jun 2025 18:20:39 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Improve the performance of Unicode Normalization Forms.
To: Jeff Davis <pgsql@j-davis.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
References: <844d3dd7-2955-4794-95d1-7f4c13cb89fc@gmail.com>
 <4211ffd7fe154c4af693b98d78f4a3689ce8cc30.camel@j-davis.com>
 <16f87504-f174-450e-93cc-2db1074522bb@gmail.com>
 <96c54fc3dde2ebaccafbd1ffa29b8be1005c8b8c.camel@j-davis.com>
Content-Language: ru
From: Alexander Borisov <lex.borisov@gmail.com>
In-Reply-To: <96c54fc3dde2ebaccafbd1ffa29b8be1005c8b8c.camel@j-davis.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/677cde50-6d64-474b-9ba8-bab380a111b3%40gmail.com>
Precedence: bulk

20.06.2025 20:20, Jeff Davis wrote:
> On Fri, 2025-06-20 at 17:51 +0300, Alexander Borisov wrote:
>> I don't quite see how this compares to the implementation on Rust. In
>> the link provided, they use perfect hash, which I get rid of and get
>> a x2 boost.
>> If you take ICU implementations in C++, I have always considered them
>> slow, at least when used in C code.
>> I may well run benchmarks and compare the performance of the approach
>> in Postgres and ICU. But this is beyond the scope of the patches
>> under
>> discussion.
> 
> Are you saying that, with these patches, Postgres will offer the
> fastest open-source Unicode normalization? If so, that would be very
> cool.

That's what we're aiming for - to implement the fastest approach.
By applying the proposed patches (two patches) we get the fastest
codepoints search by tables. This is evidenced by the measurements made
here and earlier in the patch for unicode case improvement.

After these patches are compiled, I will improve the C normalization
code directly, optimize it. That's when we can take benchmarks and say 
with confidence that we're the best at speed.

> The reason I'm asking is because, if there are multiple open source
> implementations, we should either have the best one, or just borrow
> another one as long as it has a suitable license (perhaps translating
> to C as necessary).

Before getting into this "fight" I studied different approaches to
searching for the necessary codepoints in tables (hash, binary search,
radix trees...) and came to the conclusion that the approach I proposed
(range index) is the fastest for this purpose.


--
Regards,
Alexander Borisov