DDC-718: Bottleneck in computeAssociationChanges()? #888

Open
opened 2026-01-22 12:54:05 +01:00 by admin · 3 comments
Owner

Originally created by @doctrinebot on GitHub (Jul 24, 2010).

Jira issue originally created by user @beberlei:

It seems that since DDC-600 computeAssociationChanges() iterate over entries of an collections, even if they are not marked as cascadePersist. For large, hydrated collections this could potentially become a bottleneck.

Wouldn't it be better to save the "addedEntities" in an additional map inside "PersistentCollection" and retrieve those instead of calling $value->unwrap() ?

Originally created by @doctrinebot on GitHub (Jul 24, 2010). Jira issue originally created by user @beberlei: It seems that since [DDC-600](http://www.doctrine-project.org/jira/browse/DDC-600) computeAssociationChanges() iterate over entries of an collections, even if they are not marked as cascadePersist. For large, hydrated collections this could potentially become a bottleneck. Wouldn't it be better to save the "addedEntities" in an additional map inside "PersistentCollection" and retrieve those instead of calling $value->unwrap() ?
admin added the Improvement label 2026-01-22 12:54:05 +01:00
Author
Owner

@doctrinebot commented on GitHub (Jul 24, 2010):

@doctrinebot commented on GitHub (Jul 24, 2010): - relates to [DDC-600: Persisting Entities with unmanaged related associations produces ugly notices](http://www.doctrine-project.org/jira/browse/DDC-600)
Author
Owner

@doctrinebot commented on GitHub (Jul 24, 2010):

Comment created by romanb:

Do you have any numbers to back this up? With large, hydrated collections the bottlenecks are likely elsewhere (SQL query, hydration) :)

Further, maintaining "addedEntities" is not as trivial as you might think. The current approach does not care about what happens in-between, it just computes a diff between the old and new state of the collection at commit time. Tracking added/removed objects as they come in and go is more cumbersome.

@doctrinebot commented on GitHub (Jul 24, 2010): Comment created by romanb: Do you have any numbers to back this up? With large, hydrated collections the bottlenecks are likely elsewhere (SQL query, hydration) :) Further, maintaining "addedEntities" is not as trivial as you might think. The current approach does not care about what happens in-between, it just computes a diff between the old and new state of the collection at commit time. Tracking added/removed objects as they come in and go is more cumbersome.
Author
Owner

@doctrinebot commented on GitHub (Jul 24, 2010):

Comment created by @beberlei:

no numbers, i was just confused about the code, because i remembered it differently :-)

@doctrinebot commented on GitHub (Jul 24, 2010): Comment created by @beberlei: no numbers, i was just confused about the code, because i remembered it differently :-)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#888