# What's going on with save() performance?

**URL:** https://discuss.tryton.org/t/whats-going-on-with-save-performance/2584
**Category:** Developer
**Created:** [April 14, 2020, 12:47am UTC](https://discuss.tryton.org/t/whats-going-on-with-save-performance/2584 "2020-04-14T00:47:21Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![albert](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/albert/32/21_2.png) [@albert](https://discuss.tryton.org/u/albert)
#### Post date: [April 14, 2020, 12:47am UTC](https://discuss.tryton.org/t/whats-going-on-with-save-performance/2584/1 "2020-04-14T00:47:21Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![JCavallo](https://discuss-cdn.tryton.org/letter_avatar_proxy/v4/letter/j/48db29/32.png) [@JCavallo](https://discuss.tryton.org/u/JCavallo)
#### Post date: [April 14, 2020, 7:17am UTC](https://discuss.tryton.org/t/whats-going-on-with-save-performance/2584/2 "2020-04-14T07:17:31Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![albert](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/albert/32/21_2.png) [@albert](https://discuss.tryton.org/u/albert)
#### Post date: [April 19, 2020, 10:20am UTC](https://discuss.tryton.org/t/whats-going-on-with-save-performance/2584/3 "2020-04-19T10:20:17Z")

</div>

The issue I’ve been investigating has more mundane roots. I created [Reduce save() overhead (#9240) · Issues · Tryton / Tryton · GitLab](https://bugs.tryton.org/issue9240) to address them.
