Optimize hierarchy model: use get_rest_folders instead of get_folders_hierarchy - #2073
Merged
iLLiCiTiT merged 3 commits intoSep 18, 2026
Merged
Conversation
…hy` for general speed improvement. Performance for 10,328 folders, local server, 10 repeats - OLD (`get_folders_hierarchy` full call) mean: 796.5 ms | median: 629.5 ms - NEW (`get_rest_folders` full call) mean: 235.8 ms | median: 181.6 ms - NEW + `__slots__` (full call) mean: 222.5 ms | median: 186.6 ms The slots call is a neglible ~4-6% faster in processing, however it reduces its memory usage by +/-46% and since we do keep these in cache it's a nice bonus (even though we're talking only 403 KiB saved for this dataset)
BigRoy
added
the
type: enhancement
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The new REST parsing path currently normalizes path differently than other constructors, which can create inconsistent cached paths (e.g. potential //...) and break path-based lookups/filters.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
This PR optimizes the hierarchy folder model by switching the folder-cache refresh query from ayon_api.get_folders_hierarchy (tree) to ayon_api.get_rest_folders (flat list), with an additional memory optimization on the cached FolderItem instances.
Changes:
- Replace hierarchy-tree traversal with a flat REST folders query in the folder cache refresh path.
- Introduce
FolderItem.__slots__to reduce per-item memory overhead in cached folder items. - Add
FolderItem.from_rest_data(...)for constructing cached items from REST payloads.
File summaries
| File | Description |
|---|---|
| client/ayon_core/tools/common_models/hierarchy.py | Switches folder querying to get_rest_folders, adds a REST-to-model constructor, and applies __slots__ to reduce memory usage. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 2
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
iLLiCiTiT
approved these changes
Sep 18, 2026
github-project-automation
Bot
moved this from Review In Progress
to Merge Requested
in PR reviewing
iLLiCiTiT
deleted the
enhancement/optimize_hierarchy_model_folders_query
branch
September 18, 2026 07:37
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changelog Description
Query folders with
get_rest_foldersinstead ofget_folders_hierarchyfor general speed improvement.Additional info
Performance for 10,328 folders, local server, 10 repeats
get_folders_hierarchyfull call) mean: 796.5 ms | median: 629.5 msget_rest_foldersfull call) mean: 235.8 ms | median: 181.6 ms__slots__(full call) mean: 222.5 ms | median: 186.6 msThe slots call is a neglible ~4-6% faster in processing, however it reduces its memory usage by +/-46% and since we do keep these in cache it's a nice bonus (even though we're talking only 403 KiB saved for this dataset). Since it's a minor tweak I added it.
Testing notes: