What's going on with save() performance?

Support Developer
1

I think that it’s been known for a long time that save(records) is slower (and sometimes much slower) than create([x._save_values for x in records]).

I’ve never understood why that is the case and now I’ve hit another more surprising result:

The create_moves() method of stock_forecast iterates over all forecast lines and saves all forecast lines at the end. Lines have a m2m relationship with stock moves and thus executes many create() calls so I tried simply to save() all stock moves in batch.

I was surprised to see that saving all stock moves in batch is indeed much slower than saving forecast lines.

Saving forecast lines took ~180 seconds. I wasn’t patient enough to wait for stock moves to be saved. And eventually I used create([x._save_values for x in recors]) which took 140 seconds.

What’s going on? Does anyone have a clue why save() is much slower than create() and specially why saving all stock moves in batch is slower than saving all lines? Is there something we can do about it?

2

Hello @albert,

I think this could be because records were instanciated with a different context, or one of the fields you want to save has a “context” attribute on it. So for consistency, the individual operations are done in a contextualized way to make sure create / validate calls are done in the right context.

I say this from noticing the same problem once, and tracking it down to this, though that was some time ago.

3

The issue I’ve been investigating has more mundane roots. I created Issue 9240: Reduce save() overhead - Tryton issue tracker to address them.