Comment 4 for bug 731156

Sebastien, I don't think you guys are looking at the right place.

What you are describing is not a bug, but is simply the prefetching mechanism of browse(). When opening the product list, the product.product.read() is called with the list of fields the client needs to display. Some of these fields are function fields that are implemented using browse(). And when product.product is browsed, the prefetching mechanism of browse() will simply try to load all similar "basic" fields to the one being accessed, to avoid doing more queries than is necessary.
This will not necessarily be useful for all cases, but will also not make any noticeable difference in performance, because what matters is the number of database queries that are performed.
Simple example: for postgres, it is as fast to do:
       "SELECT id, a FROM TABLE WHERE id in (1,2,3)"
than to do:
       "SELECT id, a,b,c,d,e FROM TABLE WHERE id in (1,2,3)".
But by doing the latter, browse's prefetching avoids possible queries later, because after doing "record.a" you are likely to need "record.b.". And if you don't need it, no harm was done.

What matters is: browse will only load "basic" fields, fields that can be read from the database directly,and require no further computation. Look at the list of fields that browse() passes to read() and you will see they can all be read directly from the db. To convince yourself, you can simply try to measure the difference between doing product.product.read() on just one field, e.g ['name'], and doing the same on all basic fields of product, as listed in your description. And do the same for 1 or for 100 product, and notice the difference.

What I mean is, the behavior you see is not caching done by read(), but caching done by browse(), which is reusable as long as your browse_record or browse_list is in the scope. I don't think it can be related to your performance problem, or at least not directly.

Yes of course, turning off browse's prefetching will remove that behavior, but it won't magically give you noticeably more performance, unless something else is abusing this... and turning it off *will* cause extra queries in places where browse's prefetching was useful! So be careful when you look at this..

If there is a performance problem when opening the product list in your databases, you might want to investigate further to see what is actually taking time (function fields that are not correctly written or should be stored, etc.), without making early assumptions on what you think is happening. Like for any performance problem, you need to measure precisely to understand where the source(s) of the performances issues are.

I'm setting this bug as incomplete until we have more evidence to point out to the source(s) of the issue.