doctrine/archived-orm
1
0
Fork 0
mirror of https://github.com/doctrine/orm.git synced 2026-03-23 22:42:18 +01:00
Code Issues 5.3k Packages Projects Releases 100 Wiki Activity

DDC-519: Consider turning public ClassMetadataInfo properties into a hash/array #647

New Issue
Closed
opened 2026-01-22 12:45:32 +01:00 by admin · 2 comments
admin commented 2026-01-22 12:45:32 +01:00
Owner
Copy Link

Originally created by @doctrinebot on GitHub (Apr 14, 2010).

Jira issue originally created by user romanb:

Currently all the different mapping info is stored in separate properties on ClassMetadataInfo even though in many cases most of the properties are not used / remain blank. Moving all the properties into a hash, where they are never actually created if they dont exist can potentially improve unserialization performance.

On a regular entity with no inheritance or versioning etc. the following properties remain unused, yet participate in serialization/unserialization with caching:

  • customRepositoryClassName
  • discriminatorColumn
  • discriminatorValue
  • discriminatorMap
  • inheritedAssociationFields
  • isMappedSuperclass
  • isVersioned
  • lifecycleCallbacks
  • parentClasses
  • subClasses
  • sequenceGeneratorDefinition
  • tableGeneratorDefinition
  • versionField

NOTE: The first thing that needs to be done is to evaluate whether there is an actual noticable improvement from doing this. Mainly unserialization performance is of interest. Its probably easy to do a microbenchmark with artificial classes, one with a lot of individual properties, the other with a single array property.

This might also have a positive effect on no/less overhead when adding new mapping features (we dont need new properties). I am also curious what effects the upcoming performance patches for PHP trunk have on the Doctrine code, especially string interning which will positively influence performance of string keys in arrays.

Originally created by @doctrinebot on GitHub (Apr 14, 2010). Jira issue originally created by user romanb: Currently all the different mapping info is stored in separate properties on ClassMetadataInfo even though in many cases most of the properties are not used / remain blank. Moving all the properties into a hash, where they are never actually created if they dont exist can potentially improve unserialization performance. On a regular entity with no inheritance or versioning etc. the following properties remain unused, yet participate in serialization/unserialization with caching: - customRepositoryClassName - discriminatorColumn - discriminatorValue - discriminatorMap - inheritedAssociationFields - isMappedSuperclass - isVersioned - lifecycleCallbacks - parentClasses - subClasses - sequenceGeneratorDefinition - tableGeneratorDefinition - versionField NOTE: The first thing that needs to be done is to evaluate whether there is an actual noticable improvement from doing this. Mainly unserialization performance is of interest. Its probably easy to do a microbenchmark with artificial classes, one with a lot of individual properties, the other with a single array property. This might also have a positive effect on no/less overhead when adding new mapping features (we dont need new properties). I am also curious what effects the upcoming performance patches for PHP trunk have on the Doctrine code, especially string interning which will positively influence performance of string keys in arrays.
admin added the Improvement label 2026-01-22 12:45:32 +01:00
admin closed this issue 2026-01-22 12:45:34 +01:00
admin commented 2026-01-22 12:45:34 +01:00
Author
Owner
Copy Link

@doctrinebot commented on GitHub (Apr 26, 2010):

Comment created by romanb:

First tests showed no noticable improvement by doing this. Instead serializing has been improved by only serializing what is necessary.
Furthermore association mappings might be replaced with plain arrays in the future (just like field mappings).

@doctrinebot commented on GitHub (Apr 26, 2010): Comment created by romanb: First tests showed no noticable improvement by doing this. Instead serializing has been improved by only serializing what is necessary. Furthermore association mappings might be replaced with plain arrays in the future (just like field mappings).
admin commented 2026-01-22 12:45:34 +01:00
Author
Owner
Copy Link

@doctrinebot commented on GitHub (Apr 26, 2010):

Issue was closed with resolution "Won't Fix"

@doctrinebot commented on GitHub (Apr 26, 2010): Issue was closed with resolution "Won't Fix"
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BC Break
Bug
Can't Fix
Deprecation
Documentation
DQL
Duplicate
Failing Test
Hacktoberfest
Improvement
Improvement
Incomplete
Invalid
Missing Tests
New Feature
PR Created
pull-request
Mirrored from GitHub Pull Request
 Question
Regression
Status: Waiting feedback
Waiting feedback
WIP
Won't Fix
No Label Improvement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#647
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?