doctrine/archived-orm
1
0
Fork 0
mirror of https://github.com/doctrine/orm.git synced 2026-04-29 17:33:15 +02:00
Code Issues 5.3k Packages Projects Releases 100 Wiki Activity

Cache for AttributeReader mapping reader #6929

New Issue
Closed
opened 2026-01-22 15:41:35 +01:00 by admin · 3 comments
admin commented 2026-01-22 15:41:35 +01:00
Owner
Copy Link
Copy Source

Originally created by @boesing on GitHub (Feb 15, 2022).

Feature Request

Q A
New Feature yes
RFC yes
BC Break no

Summary

Hey there,

I do actually miss the AttributeReader cache (there was a cache for the annotations and that safed a hell lot of repeated parsings).
Was there an active decision against such a cached reader?
Is this something to be of interest here?
Is reading from a filesystem cache more performant than using ReflectionClass on entities?
(Haven't made actual benchmarks but from my experience with laminas-hydrator, I do know that using reflection is actually insanely slow)

Would love to get some feedback here and if this is of interest, I'm happy to contribute that cached reader for attributes.

Originally created by @boesing on GitHub (Feb 15, 2022). ### Feature Request <!-- Fill in the relevant information below to help triage your issue. --> | Q | A |------------ | ------ | New Feature | yes | RFC | yes | BC Break | no #### Summary Hey there, I do actually miss the `AttributeReader` cache (there was a cache for the annotations and that safed a hell lot of repeated parsings). Was there an active decision against such a cached reader? Is this something to be of interest here? Is reading from a filesystem cache more performant than using `ReflectionClass` on entities? (Haven't made actual benchmarks but from my experience with `laminas-hydrator`, I do know that using reflection is actually insanely slow) Would love to get some feedback here and if this is of interest, I'm happy to contribute that cached reader for attributes.
admin added the New Feature label 2026-01-22 15:41:35 +01:00
admin closed this issue 2026-01-22 15:41:35 +01:00
admin commented 2026-01-22 15:41:36 +01:00
Author
Owner
Copy Link
Copy Source

@derrabus commented on GitHub (Feb 15, 2022):

The cached annotations reader was reasonable because annotations had to be parsed in userland out of an elements doc block.

With attributes, parsing is done by the PHP interpreter itself. Our cache in this case should be PHP's own opcache. Are attributes performing measurably worse than Doctrine Annotations in your case?

@derrabus commented on GitHub (Feb 15, 2022): The cached annotations reader was reasonable because annotations had to be parsed in userland out of an elements doc block. With attributes, parsing is done by the PHP interpreter itself. Our cache in this case should be PHP's own opcache. Are attributes performing measurably worse than Doctrine Annotations in your case?
admin commented 2026-01-22 15:41:36 +01:00
Author
Owner
Copy Link
Copy Source

@boesing commented on GitHub (Feb 15, 2022):

No, I haven't verified this yet (no benchmarks).
And I think, that it might be less problematic as every class metadata already contains the ReflectionClass and thus the performance impact might not be that huge as I assume.

I just realized performance issues when using ReflectionClass along with laminas-hydrator (ReflectionHydrator) but that was due to the fact that ReflectionClass was called multiple times even tho it was already instantiated in the past. Somehow, this was not cached by opcache (but maybe opcache was disabled in my debugging) and thus lead to performance gaps.
Since the metadata is cached in-memory, the attribute parsing will only happen once and thus I think I would be fine without such a cache in-place.

@boesing commented on GitHub (Feb 15, 2022): No, I haven't verified this yet (no benchmarks). And I think, that it might be less problematic as every class metadata already contains the `ReflectionClass` and thus the performance impact might not be that huge as I assume. I just realized performance issues when using `ReflectionClass` along with `laminas-hydrator` (`ReflectionHydrator`) but that was due to the fact that `ReflectionClass` was called multiple times even tho it was already instantiated in the past. Somehow, this was not cached by opcache (but maybe opcache was disabled in my debugging) and thus lead to performance gaps. Since the metadata is cached in-memory, the attribute parsing will only happen once and thus I think I would be fine without such a cache in-place.
admin commented 2026-01-22 15:41:36 +01:00
Author
Owner
Copy Link
Copy Source

@derrabus commented on GitHub (Feb 15, 2022):

All right. I'm closing this ticket for now. If you encounter actual performance issues that might be solved by introducing a cache to the reader, feel free to reopen.

@derrabus commented on GitHub (Feb 15, 2022): All right. I'm closing this ticket for now. If you encounter actual performance issues that might be solved by introducing a cache to the reader, feel free to reopen.
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 New Feature
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#6929
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?