openerp-expert-framework team mailing list archive

[Xavier Morel <xmo@xxxxxxxxxxx>]

On 3 Feb 2010, at 09:29 , P. Christeas wrote:
> 
> On Wednesday 03 February 2010, you wrote:
>> Blueprint changed by Xavier (Open ERP):
>>  2. Though it's not quite ideal (understatement of the day), the
>>  `NUMERIC` postgres type...
> 
> Are we sure all this will not introduce a performance issue on the server?
> 
I'm not. But I do believe there's more than enough overhead elsewhere to dwarf anything which would be introduced by switching from float to decimal where it makes sense (accounting, mostly, I'd guess). It's not like every single real value would be switched to fixed-point.

> AFAIK, postgres suggests that NUMERIC is slower than float. Yes, float is bound 
> to have rounding errors (actually noticable if we bring it to less than 2 
> decimal places from the precision we want) [1], but it's much faster.
> 
Naturally, and likewise python's decimal.Decimal is slower than float. Most CPUs don't have native fixed-point units (whereas every x86 CPU since the 80486 has FPU integrated in the base core), so that's bound to happen. The problem is more along the lines of knowing whether using floats are correct. Something that goes fast but returns the wrong result isn't very useful.

> Could we write a dummy python (standalone) program and test performance with 
> SQL's numeric, float, and python's Decimal etc?
> 
That wouldn't be too hard to do, but it would be like every other microbenchmark: not very informative as far as "real-world" cases go.

> [1] I mean, if we want NUMERIC(12,4), and float can have 6 decimal places for 
> the range we use, then float maps ok. If float drops down to 4, we could 
> introduce a +-1 digit difference (actually mathematically correct for non-
> trivial calculations). If, again, we only use NUMERIC(12,2) for 2-decimal 
> money (like Eur), numeric already calcs wrong (eg. for VAT).
I believe this is a problem, computations are not supposed to be done wrong are they? Aren't there some kind of euro/world standards on the subject?

> [3] There is many unfortunate python loops in the code, which keep querying 
> the SQL for results, separately per orm row.
These should probably be profiled and optimized, if they really are sources of slowness.

--
Xavier Morel
Developper
OpenERP - Tiny SPRL
Chaussee de Namur, 40
B-1367 Gerompont
Tel: +32.81.81.37.00
Web: http://www.tiny.be
Web: http://www.openerp.com
Planet: http://www.openerp.com/planet/