Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion for DB mappers: Enhance memory usage on load #306

Open
adkurz opened this issue Nov 2, 2020 · 2 comments
Open

Suggestion for DB mappers: Enhance memory usage on load #306

adkurz opened this issue Nov 2, 2020 · 2 comments
Labels

Comments

@adkurz
Copy link

adkurz commented Nov 2, 2020

Hello,
I tested the memory usage of the DB Mappers of F3 with different actions.
I noticed that the load method needs almost as much memory as the find method. The cause is that a load use the find method and saves an array of all mapped records in the memory. This leads to a high memory usage if I have to process very much records. Of curse, I could use the paginate method, but this is not a very good choice because of complicated usage of loops.
Because of this, I have a suggestion. The load method shouldn't use the find method anymore. I recommend to store only the results of the internal select method before it calls the factory method to convert the results to new mapper objects.
With every call to next() or skip(), the next item of the results array should be processed in the factory method. This would considerable reduce the memory usage.
I hope this was understandable.
Greetings

@ikkez
Copy link
Member

ikkez commented Nov 2, 2020

Hi, yes it's understandable and I also noticed this already. To change this however, I'm not sure if it would be a breaking change, as we probably would refactor usage of the protected $query property, and I know from people that they're misusing it. So I'd like to improve this, but perhaps move that to v4. And yes, I know v4 is more a less becoming a legend, but I think we'll have plenty of time this winter to finally do the jump ;)

@ikkez ikkez added the v4 label Nov 2, 2020
@adkurz
Copy link
Author

adkurz commented Nov 2, 2020

Yes, sounds reasonable. Is there already a road map or a dev branch for the v4?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants