c2c-oerpscenario team mailing list archive

["Olivier Dony \(OpenERP\)" <709567@xxxxxxxxxxxxxxxxxx>]

Here is a very short sample of timing the various parts of the
operations, performed on a local server with the latest trunk (hopefully
LP preserves the formatting):

|  #  | A  | B  | C |  D  |
|  64 |  7 |  5 | 2 | 15  |
| 128 | 14 | 11 | 3 | 56  |
| 256 | 28 | 21 | 4 | 232 |

with:
#: lines in purchase.order
A: time to confirm po (seconds)
B: time to duplicate po (seconds)
C: time to open picking processing wizard (seconds)
D: time to process picking with wizard (seconds)

This not only confirms that step D has a total time in O(n2), which is
too much (to be fixed by bug 709575), but also shows that the name_get()
calls from the client, counted in column C, are almost negligible, even
if YMMV depending on the network speed (this is the current bug).

Given that we are already considering extreme cases here, with a wizard that include hundreds of m2o values, the performance improvement of fixing the current bug in 6.0 seems totally irrelevant compared to the huge impact of changing the API at this stage.
This change is likely to require patching 80% of osv_memory wizards when going from 6.0.1 to 6.0.2, i.e. a minor/patch version update! And not only for core addons, but all community addons too. This is against all stable policies. Imagine the regression risk, even with yaml tests in place and careful manual check.

As a conclusion, we won't change this in 6.0, but will do it as soon as possible in trunk. Progress can be followed in the work-in-progress branches:
server: lp:~openerp-dev/openobject-server/trunk-fix-osvmem-read
addons: lp:~openerp/openobject-addons/trunk-fix-osvmem-read


PS: if you still want to experience the small perf boost in 6.0 without the global impact of the API change, you can try this server 6.0 branch, which contains a special 'osv_memory_v610' class: lp:~openerp-dev/openobject-server/6.0-osv-mem-v610. Then make whatever wizard you want (e.g stock.move.memory.out) inherit osv_memory_v610 instead of osv_memory, and you will have the same benefits. But the difference isn't probably worth it... 

** Summary changed:

- [6.0.1] many2one fields should be read as (id, name) also for osv_memory objects (saving name_get RPC calls)
+ [trunk] many2one fields should be read as (id, name) also for osv_memory objects (saving name_get RPC calls)

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/709567

Title:
  [trunk] many2one fields should be read as (id, name) also for
  osv_memory objects (saving name_get RPC calls)

Status in OpenERP Server:
  In Progress

Bug description:
  Hello,

  I've a production case with 315 moves in a picking, when clicking on
  process, the wizard last for nearly a minute to appear depending on
  your network latency because it makes a name_get RPC call for each
  line instead of reading it by batch, see the following GTK RPC logs +
  full description here (I open a new bug as those are separated
  concerns): https://bugs.launchpad.net/openobject-addons/+bug/709559