-
Notifications
You must be signed in to change notification settings - Fork 333
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
TreeDropdownField is very slow when there's lots of nodes in the query #2265
Comments
For the record, I think we should change Looking at the API surface of this class, we need to keep the terminology ("tree", "children", etc). But there is no reason to "mark" a tree, which seems to be the expensive bit. If you're in search mode, the results are a simple list, there's no "tree view" (other than breadcrumbs). If you're not in search mode, there's no "mark to expose" required to expand a tree to a certain node, since you're always operating in a flat list (with child navigation actions). I've checked back with the refactoring work (silverstripe/silverstripe-framework#6141), and it looks like we don't have a "legacy view" of this any more - There's This would obviously be a bit of a larger refactoring, but a worthwhile one. We're likely to throw away the entire cursed "tree marking" logic when we re-implement the tree in React, and moving this level of state management to the client instead. This gets us closer to this goal. |
FYI this is a payload from a three level small tree view. It's including all three levels (since it's under the node threshold of ~250). That's neat, but not essential. We could just implement the first two levels with a simple loop (no complex tree marking), and then use further XHR requests to dig in further. https://gist.github.com/chillu/4e17e3e08d7134dcaf952239bc42d101 |
I had a quick look specifically at the TreeDropdown on my box. When looking at the settings for Page ID 7772 (
Those 3 calls are running concurrently. If you run them individually, they come back in 4.7 sec, 4.7 sec and 6.0 sec respectively. I tried firing off that same request in 5 different tabs and some of those tree calls were taking over a minute ... which is kind of nuts. One confusing bit is that there's only 4 groups in the site and fetching them takes 4.7 sec. So there's something else at play here other than the volume of data. I'll concentrate on this part first. A second thing we could look at is delaying the call until the user actually interacts with the TreeDownField. I'll have a look at that part afterwards. |
Found the culprit! It's Each call to the If I comment out the |
Once we implement a fix for silverstripe/silverstripe-admin#621, the Delaying the |
We've found some project code that was the major contributor to this bug so this can probably be closed. One thing to note, however, is that we originally tried setting the |
Longer term solution: Take the XHR out of nested controllers, and make it talk GraphQL. #2271 |
Our key project has found alternative solution to this, that is very specific to them. There's nothing else left to look at with this card, so I'll just close it for now. |
This is related to #2250 (comment)
TreeDropownField
is populated by doing AJAX calls to atree
action. These calls can take 15sec+ on a key project. Maybe fixing #2250 will fix this call as well ... or we might need a custom implementation for theTreeDropdownField
.The text was updated successfully, but these errors were encountered: