-
Notifications
You must be signed in to change notification settings - Fork 824
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
Precache Hierarchy::numChildren() for performance #8379
Comments
Closed
1 task
I'd be keen to get @tractorcow's thoughts on this. |
sminnee
pushed a commit
to sminnee/silverstripe-cms
that referenced
this issue
Sep 18, 2018
Only relevant if silverstripe/silverstripe-framework#8380 is avialable, however coded defensively so it can be merged before that PR if needs be. See silverstripe/silverstripe-framework#8379
Note that this might best be refactored as part of #8391. |
sminnee
pushed a commit
to sminnee/silverstripe-cms
that referenced
this issue
Sep 21, 2018
Only relevant if silverstripe/silverstripe-framework#8380 is avialable, however coded defensively so it can be merged before that PR if needs be. See silverstripe/silverstripe-framework#8379
maxime-rainville
pushed a commit
that referenced
this issue
Sep 25, 2018
* NEW: Add Hierarchy::prepopulate_numchildren_cache() API: Hierarchy::stageChildren() customisations must be applied to the base class and not include record-specific behaviour. Adds the ability to prepopulate the cache for Hierarchy::numChildren() in a batch. Note that this optimisation means that stageChildren() is not called on each record in order to calculate numChildren(). This means that the structure of the stageChildren() query must be the same for all records and the behaviour cannot be customised only for a subclass of the base data class. For example, apply your customisations to SiteTree and not a subclass. This is an useful part of optimising the query count on tree generation. See #8379 * NEW: Add Hierarchy::prepopulateTreeDataCache() This provides a more extensible way of preopulating caches for optimised tree generation. Fixes #8391
maxime-rainville
pushed a commit
to silverstripe/silverstripe-cms
that referenced
this issue
Sep 25, 2018
* FIX: Use Hierarchy::prepopulate_numchildren_cache in tree-generation Only relevant if silverstripe/silverstripe-framework#8380 is avialable, however coded defensively so it can be merged before that PR if needs be. See silverstripe/silverstripe-framework#8379 * FIX: Use Hierarchy::prepopulateTreeDataCache() in CMS. Requires silverstripe/silverstripe-framework#8395 * Cache tree_class instead of assuming it will always be SiteTree.
I believe that we can close this one now, @maxime-rainville @ScopeyNZ? |
I'll leave @maxime-rainville to confirm but I'm happy to close it. |
Yes ... we're all done here. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The CMS treeview makes heavy use of
Hierachy::numChildren()
and its caching feature should be extended to allow precaching in a similar manner to Versioned::prepopulate_versionnumber_cache.There is a call to Hierarchy::numChildren() for every tree-item shown in the CMS. This accounts for the bulk of time calling treeview / getsubtree URL requests, at least in cases where silverstripe/silverstripe-versioned#181 has been applied.
Approach
augmentStageChildren deprecation
It would be difficult to make this work with augmentStageChildren. I can't see many places where augmentStageChildren is used (it's not used in any of the supported modules, as far as I can see), and my recommendation is that we deprecate it in order to implement this performance features.
CMS update
Once this change has been made, CMSMain::SiteTreeAsUL can make calls to
Hierarchy::prepopulate_numchildren_cache
The text was updated successfully, but these errors were encountered: