#11977 implemented batching of INSERT operations in UnitOfWork#executeInserts() so that EntityPersister#executeInserts() calls are reduced#11978
Conversation
…SERT` operations in `UnitOfWork#executeInserts()` This logic also brings a minor benefit in reducing the number of times `ListenersInvoker#getSubscribedSystems` is queried. TODOs: * [ ] integration test this - it is expected to reduce the number of `EntityPersister#executeInserts()` calls * [ ] refactor this by creating a new `@internal` class for the batch, and perhaps batch via a generator * [ ] reduce amount of repeated `getClassMetadata()` calls * [ ] reduce overall size of `UnitOfWork` code, instead of increasing it
…performance-sensitive class
…g used to batch `INSERT`s
INSERT operations in UnitOfWork#executeInserts()INSERT operations in UnitOfWork#executeInserts() so that EntityPersister#executeInserts() calls are reduced
…quential batches
…is in use The `SequenceGenerator` is potentially used for PostgreSQL table auto-generated fields, but the `SequenceGenerator` is not a **POST**-insert generator. Because the `SequenceGenerator` is used in the middle of `INSERT` operations performed by persisters, we cannot rely on it in batching operations: disabling it, so we get a green test suite on PostgreSQL. This change makes `GH10531Test` pass on PostgreSQL: see doctrine#10531
|
I ran a local benchmark, and everything seems fine from a regression PoV: +-----------------------------------------------------------+-----------------------------------------------------+-----+------+-----+----------+---------------+---------+
| benchmark | subject | set | revs | its | mem_peak | mode | rstdev |
+-----------------------------------------------------------+-----------------------------------------------------+-----+------+-----+----------+---------------+---------+
- | SimpleInsertPerformanceBench | benchHydration | | 5 | 10 | 12.890mb | 25,634.255μs | ±3.28% |
+ | SimpleInsertPerformanceBench | benchHydration | | 5 | 10 | 12.890mb | 25,701.962μs | ±4.43% | |
…rred by the parameters
|
BTW, I'd say that it is a good idea to roll out a minor release with just this change applied, to see if there's a real-world impact already. Adding batching to the |
…d vs generated-id entities As noted by @bendavies Ref: doctrine#11978 (comment)
I just released 3.4.0, so it would be possible to do this by releasing this PR in 3.5.0. |
|
Base branch is updated 👍 |
|
@greg0ire can this be milestoned/merged please? |
|
Sure! Thanks! |
Released as https://github.com/doctrine/orm/releases/tag/3.5.0 The change is not alone in this milestone, but I don't think the other changes will impact performance. |
|
Thanks @greg0ire! |
This logic also brings a minor benefit in reducing the number of times
ListenersInvoker#getSubscribedSystemsis queried.Implements #11977
TODOs:
EntityPersister#executeInserts()calls@internalclass for the batch, and perhaps batch via a generatorgetClassMetadata()callsUnitOfWorkcode, instead of increasing itThe final effect of this patch is that
EntityPersister#executeInserts()will be performed on a batch of entities being persisted, which improves efficiency, since a single prepared statement is re-used to perform allINSERToperations.