Comment 7 for bug 307718

Ok, after analysing the queries at SQL level, here is the results for
products.

In list view (without opening the form view before)::w

Reading 1 product: 32 queries
Reading 29 products: 34 queries

So we can assume it's the same. But in form views:

Reading 1 product: 147 queries
Reading 29 products: 1033 queries

After analysis, the problem come from the fields computing prices for
each pricelists. I stored them in DB, the result is now, in form view:

Reading 1 product: 76 queries
Reading 29 products: 76 queries

After having activated the cache on translations of fields:

Reading 1 product: 52 queries
Reading 29 products: 54 queries

So, we went from O(n) to O(1) for products. Let me know if you find
others objects that are in O(1).

Such number of queries is really normal. For instance, just displaying
the category in a product: All Products / Sellable Products /

So, please du bzr up and tell me if it's ok. To avoid such problems in
the futur (bad developped fields.function that results in O(1)
computations), we developped a module that analyses the quality of a
module: base_module_quality. It checks for O(n) or O(n2) in readings
records.

Tell me if it's ok now.
Thanks for the good feedback,

Raphaël Valyi - http://www.Smile.fr wrote:
> Some experiments with a real near-production database:
>
> With a limit of 80 products in the product list, opening a product form
> taks 5''90 (nearly 6 seconds, far too much!)
>
> But if I decrease that number of records, here is the figures I'm
> getting:
>
> 80 records -> time: 5''90
> 40 records -> time: 3''
> 20 records -> time: 1''60
> 10 records -> time: 0''80
>
> 1 record -> time 0''18
>
>
> So I mean, this is nothing like 'it will be the same single request for Posgres...' No, th reality is that the number of records in the list makes the time to open the first product form almost linear (nothing like almost time constant). So I mean it does matter. Decreasing the number of records to around 20 for us in that form might be an acceptable workaround for us, but I mean, this is certainly an hot topic for you.
>
> Oh, by the way, it means that if you weren't pre-caching the all the
> records at the first request, switching to the next ond previous records
> here will only take around 0.18 seconds so I mean this would probably be
> far more acceptable than the 6 seonds lag at first access. Sorry, but
> can't really understand your default choice, I mean at least letting a
> per-action window choice would be great.
>
>
> Hope this helps,
>
> Raphaël Valyi.
>

--
Fabien Pinckaers
CEO Tiny - OpenERP Editor
Chaussée de Namur 40
B-1367 Grand-Rosière
Belgium
Phone: +32.81.81.37.00
Fax: +32.81.73.35.01
Web: http://openerp.com

Great Achievements Start With Tiny Investments
   -- Marty, 2005