Odoo GTK Client (MOVED TO GITHUB)

Bug #307718
Comment #4

Comment 4 for bug 307718

Revision history for this message

Fabien (Open ERP) (fp-tinyerp) wrote on 2008-12-15: Re: [Bug 307718] Re: TOO MANY READS WHEN VIEWING A FORM VIEW: VERY SERIOUS PERF KILLER!

I am thinking about loading nested_view by default so that the client
just have to do one and only one fields_view_get.

The product form is special, because you have all computations for the
stock in this form. And we can not compute/store these values based on
stock moves.
If you remove some of these fields (incoming, outgoing, ...) it will be
much more faster. May be putting a button on the form to display stock
and it computes only if you click on this button.

Thanks,

Raphaël Valyi - http://www.Smile.fr wrote:
> OK, I understand what you mean.
>
> Still, opening a product form is very slow at first access: After my experiments:
> * the GTK Client would busy the server arround 1.2 seconds for that.
> * Among those 1.2 seconds, nearly 0.8 seconds is for the fat read all the world request I was talking about (0.69 here)
>
>
> * After what does the web client instead, we can infer that reading only the selected id, would on the contrary take only 0.1 second
>
> => This means the request could take 0.5 sec instead of 1.2 sec. More
> than twice as fast. Of course next requests (NEXT and PREVIOUS buttons)
> would be slower.
>
> Still, as many user find this first product form access very slow, I think that would be better to double the speed here as it's easy to do.
> Then, why not eventually load the other items once the selected product is loaded so that NEXT and PREVIOUS buttons will be as fast as now? Of course that would increase the overall server load a bit, but that would make a better user experience.
>
> For me a workaround is to decrease the number of products shown here in
> the list as for now.
>
> Technically speking I don't know why the number of selected products in
> the read is so much important indeed (this it what number tells, sorry).
> You say they are part of the same SQL request and it looks like but
> there must be something because numbers are so different. I was
> wondering if that was because of Python computed fields, but I'm not
> sure it is, because I couldn't find them listed in the giant read. Any
> thought why the number in the read has so much impact?
>

--
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

I am thinking about loading nested_view by default so that the client 
just have to do one and only one fields_view_get.

The product form is special, because you have all computations for the 
stock in this form. And we can not compute/store these values based on 
stock moves.
If you remove some of these fields (incoming, outgoing, ...) it will be 
much more faster. May be putting a button on the form to display stock 
and it computes only if you click on this button.

Thanks,

Raphaël Valyi - http://www.Smile.fr wrote:
> OK, I understand what you mean.
> 
> Still, opening a product form is very slow at first access: After my experiments: 
> * the GTK Client would busy the server arround 1.2 seconds for that.
> * Among those 1.2 seconds, nearly 0.8 seconds is for the fat read all the world request I was talking about (0.69 here)
> 
> 
> * After what does the web client instead, we can infer that reading only the selected id, would on the contrary take only 0.1 second
> 
> => This means the request could take 0.5 sec instead of 1.2 sec. More
> than twice as fast. Of course next requests (NEXT and PREVIOUS buttons)
> would be slower.
> 
> Still, as many user find this first product form access very slow, I think that would be better to double the speed here as it's easy to do.
> Then, why not eventually load the other items once the selected product is loaded so that NEXT and PREVIOUS buttons will be as fast as now? Of course that would increase the overall server load a bit, but that would make a better user experience.
> 
> For me a workaround is to decrease the number of products shown here in
> the list as for now.
> 
> Technically speking I don't know why the number of selected products in
> the read is so much important indeed (this it what number tells, sorry).
> You say they are part of the same SQL request and it looks like but
> there must be something because numbers are so different. I was
> wondering if that was because of Python computed fields, but I'm not
> sure it is, because I couldn't find them listed in the giant read. Any
> thought why the number in the read has so much impact?
>

-- 
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