16.02.2022 11:45, Alex Peshkoff via Firebird-devel wrote:
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.

  I refers to this piece of code:

        // compress coeff - 3 decimal digits (999) per 10 bits (1023)
        unsigned char* p = coeff;
        for (ShiftTable* t = table; p < end; p += 3)
        {
                USHORT val = p[0] * 100 + p[1] * 10 + p[2];
                fb_assert(val < 1000);       // 1024, 10 bit
                *k |= (val >> t->rshift);
                ++k;
                *k = (val << t->lshift);
                if (!t->lshift)
                {
                        ++k;
                        *k = 0;
                        t = table;
                }
                else
                        ++t;
        }



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.

  Yes, I have same concerns. We could extract packed BCD from decFloat, btw, 
but it
seems as not very convenient for us (see decDoubleToPacked\decQuadToPacked):

pack receives DECDOUBLE_Pmax packed decimal digits (one digit per four-bit 
nibble)
followed by a sign nibble and prefixed (for decDouble and decQuad only) with an 
extra
pad nibble (which is 0).

Regards,
Vlad


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to