Message-ID: <7b76973b-e9b6-4f80-a1d2-4bd467e38346@gmail.com>
Date: Mon, 22 Dec 2025 20:55:28 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Improve the performance of Unicode Normalization Forms.
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Jeff Davis <pgsql@j-davis.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
References: <844d3dd7-2955-4794-95d1-7f4c13cb89fc@gmail.com>
 <96c54fc3dde2ebaccafbd1ffa29b8be1005c8b8c.camel@j-davis.com>
 <677cde50-6d64-474b-9ba8-bab380a111b3@gmail.com>
 <599663a8d5948243bd87bf55a4f76bbb4a51a6e8.camel@j-davis.com>
 <85f2a36f-f70a-4667-be48-49b652457295@gmail.com>
 <088432f3-a3a9-4c40-8295-6c687c25d651@gmail.com>
 <adffa1fbdb867d5a11c9a8211cde3bdb1e208823.camel@j-davis.com>
 <cffe5df6-b2de-4f72-ad22-023208409aa5@gmail.com>
 <f3fee95b221846b7ab6b08ddfad039518c6aa97b.camel@j-davis.com>
 <1260f607-8d90-4cf2-accc-45aa6eab63d8@gmail.com>
 <7859e5ef-a574-4199-a69b-6fee26711521@gmail.com>
 <CAGnEbohehx6sty5LFBkXqYKs7sB1qpy2YV1yu=n9X63ereosjQ@mail.gmail.com>
 <11f371fe-9c97-4c71-957a-a4cd3813cc55@gmail.com>
 <5f8639d99dab0d95dc1ef8f3abd4aa3adc0332ee.camel@j-davis.com>
 <e2e771aa-87aa-46d8-b547-8e73d49207f1@gmail.com>
 <ec5c5854-226b-4105-88e1-efa7dc05fba4@iki.fi>
 <58c6cea8-a5b1-4a8a-8044-18ef0011a168@gmail.com>
 <f584418b-c704-4308-b1cb-b667d99c0c6f@iki.fi>
Content-Language: ru
From: Alexander Borisov <lex.borisov@gmail.com>
In-Reply-To: <f584418b-c704-4308-b1cb-b667d99c0c6f@iki.fi>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/7b76973b-e9b6-4f80-a1d2-4bd467e38346%40gmail.com>
Precedence: bulk

22.12.2025 19:24, Heikki Linnakangas wrote:
> On 22/12/2025 17:44, Alexander Borisov wrote:
>> The branching kept bothering me. The algorithm consisted of a function
>> with branches (essentially a binary search with offsets) and a table of
>> indexes. I really wanted to get rid of the branches. And then it dawned
>> on me that instead of building branches with offsets, I could create
>> another table that would contain these offsets.
>> The "inspiration" came from my patch Optimization of the is_normalized()
>> function [0].
>>
>> Actually, I changed the GenerateSparseArray algorithm, which now
>> generates a table with offsets instead of a function with branches.
>> In other words, we now have two tables:
>> 1. A table with offsets, indicating what offset is needed to obtain the
>>     desired index from the index table.
>> 2. A table with indexes. The data is divided into fixed ranges.
> 
> Sounds like you re-invented the radix tree :-). Nothing wrong with that; 
> a radix tree sounds like a good data structure for this.

I looked at the implementation of radix trees for Encoding in
PostgreSQL. There are similarities, of course, but in my implementation,
the access speed is literally O(1).

For example:
return table_index[ table_offset[cp >> 6] + (cp & 63) ];

Access speed in Encoding (radix tree), it is more complicated. If I 
understand correctly.

In general, there was an idea to store offset and index data in one
table. Not to separate them.
But I'm sure you'll understand everything when you see the code.

>>  > The GenerateSparseArray adds comments like "/* U+1234 */" to each
>>  > element. That's nice but it implies that the elements are unicode code
>>  > points. GenerateSparseArray could be used for many other things. Let's
>>  > use "/* 0x1234 */" instead, or make it somehow configurable.
>>  >
>>  > The generated file is very large, over 1 MB. I guess it doesn't matter
>>  > all that much, but perhaps we should generate a little more compact
>>  > code. Maybe we don't need the "/* U+1234 */" comment on every line, 
>> but
>>  > only one comment for each range, for example.
>>
>> I have many places where I need to generate C tables. To make my life
>> easier, and perhaps the lives of others, I added a small module for
>> generating "pretty" tables. ./src/tools/PrettyLine.pm
>> After applying it, the size of the generated header file was reduced
>> to ~300KB.
> 
> I think a fixed number of values per line would look nicer than trying 
> to pack as much possible on each line.
> 
> (This isn't too important of course, this is just about making the 
> generated code look prettier.)

With a sense of inner beauty :), when the number of values in a line is
fixed, the lines start to "dance", which doesn't look very good.
On the other hand, we can convert all values to %06X or something like
that. But then it would defeat the whole purpose of the idea — to reduce
the file size and make it look nice.
I use this approach to create many tables, which allows me not to think
about how the numbers will fit in and not waste time on it.
But, it's more a matter of taste.

> Thanks, I'll try to find time to take a closer look.

Thank you for your time.

--
Regards,
Alexander Borisov