On 2/15/22 18:20, Vlad Khorsun wrote:
I'd vote to remove idx_numeric2 in favour of idx_decimal
Appears to be good idea.
and look how to improve
Decimal128::makeIndexKey() performance. For example, it stores every 3
decimal
digits into 10 bits using relatively complex (computationally)
algorithm with
shifts and multiplications.
To be precise - 9 digits into ULONG. No shifts (BTW what a problem with
them, CPUs have appropriate fast support since first pentium or even
more). There is one division of small integer (range from 0 to 33). It
can be easily replaced with table lookup but I'm not sure is it worth
doing or not - small numbers division if fast enough.
For Decimal34 use of packed BCD will cause growth of index key (+1
DWORD). I doubt that can make overall result better. May be we can move
2 digits in the end of exponent's DWORD, in that case we do not loose
in key size. But is that faster or slower compared with current should
be checked.
For Decimal16 I see no such problems - packed BCD can be used w/o problems.
Storing every digit in 4 bits will use 2 bits per 3
digits more but should save come CPU circles, I believe.
There is also extracting of BCD from internal decfloat representation.
Also not too fast process.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
