-
-
Notifications
You must be signed in to change notification settings - Fork 71
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
Improve the performance even more (part 2/3) #46
Comments
Part 1 of improvement is on its way to be released. The SQL statement cache improves query generation by 25%. Status: complete. |
Part 2: internal Cycle optimizations. Minor improvements in Node parsers and data typecast will lead to 15% performance improvement as the hottest part of the selection. Status: complete. |
Part 3: The command graph can be sorted on relation level, then iterated over the list of object nodes essentially extracting the dependency matrix from the Command itself. It will require graph baking but should significantly increase persist performance and also reduce memory footprint (with active memorization). |
Based on this benchmark https://github.com/adrianmiu/forked-php-orm-benchmark the ORM is pretty slow currently compared to competitors.
The reference test:
![Без названия](https://user-images.githubusercontent.com/796136/71485561-b80bc680-2822-11ea-8749-d34c81220b5b.png)
Current results:
![Screenshot_136](https://user-images.githubusercontent.com/796136/72261677-528f4680-3626-11ea-928e-9783ff843387.png)
The ideal optimizations based on cached nodes and generated mappers looks like:
![Screenshot_69](https://user-images.githubusercontent.com/796136/72221237-bc95e600-3569-11ea-8c55-a3591bcf9898.png)
Need to abstract Node Parsers into its own factory so:
The persist most likely can't be optimized a lot due to the nature of the graph traversal algorithm.
The text was updated successfully, but these errors were encountered: