Re: speed up unicode normalization quick check

Поиск
Список
Период
Сортировка
От John Naylor
Тема Re: speed up unicode normalization quick check
Дата
Msg-id CACPNZCufzUxGCFdZ9L_6t2uPpDfqEcTs0e9a-3A_qONcH-=D4A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: speed up unicode normalization quick check  (Mark Dilger <mark.dilger@enterprisedb.com>)
Ответы Re: speed up unicode normalization quick check
Список pgsql-hackers
On Sat, Sep 19, 2020 at 1:46 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:

> 0002 and 0003 look good to me.  I like the way you cleaned up a bit with the unicode_norm_props struct, which makes
thecode a bit more tidy, and on my compiler under -O2 it does not generate any extra runtime dereferences, as the
compilercan see through the struct just fine.  My only concern would be if some other compilers might not see through
thestruct, resulting in a runtime performance cost?  I wouldn't even ask, except that qc_hash_lookup is called in a
fairlytight loop. 

(I assume you mean unicode_norm_info) Yeah, that usage was copied from
the keyword list code. I believe it was done for the convenience of
the callers. That is worth something, and so is consistency. That
said, I'd be curious if there is a measurable impact for some
platforms.

>  In your commit message for 0001 you mentioned testing on a multiplicity of compilers.  Did you do that for 0002 and
0003as well? 

For that, I was simply using godbolt.org to test compiling the
multiplications down to shift-and-adds. Very widespread, I only
remember MSVC as not doing it. I'm not sure a few extra cycles would
have been noticeable here, but it can't hurt to have that guarantee.

--
John Naylor                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Collation versioning
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: speed up unicode normalization quick check