wieck@debis.com (Jan Wieck) writes:
>> > We certainly should think about a general speedup of NUMERIC.
>>
>> How would we do that? I assumed it was already pretty optimized.
>
> The speedup (I expect) results from the fact that the inner
> loops of add, subtract and multiply will then handle 4
> decimal digits per cycle instead of one! Doing a
>
> 1234.5678 + 2345.6789
>
> then needs 2 internal cycles instead of 8. And
>
> 100.123 + 12030.12345
>
> needs 4 cycles instead of 10 (because the decimal point has
> the same meaning in base 10000 the last value is stored
> internally as short ints 1, 2030, 1234, 5000). This is the
> worst case and it still saved 60% of the innermost cycles!
The question, though, becomes what percentage of operations on a
NUMERIC field are arithmetic, and what percentage are storage/retrieval.
For databases that simply store/retrieve data, your "optimization" will have
the effect of significantly increasing format conversion overhead. With a
512-byte table, four packed-decimal digits can be converted in two
primitive operations, but base-10000 will require three divisions,
three subtractions, four additions, plus miscellaneous data shuffling.
-Michael Robinson
