Drop down selection lag
We have a list that is ~1500 items long. We've published this as a list formatted line item because users like to have the drop-down selection for various reasons, but we've noticed there is ~2-3 seconds of lag before the list opens.
We cannot reduce the selection materially with a dependent list and we'd also prefer not to publish it as a line item selector separate from the grid.
I'm wondering if anyone has any ideas to help us reduce the lag time?
I tried testing this in the New UX with a module that has over 100 line items with lots of calculations and 150,000 list items. I added a grid with a drop down for the 150,000 list items and it opened sub-second. I also tried creating a field card and I was able to get the same result. The lag you experience can be a number of things. Some ideas to find the root cause
- Try a list with 10/50/100 list items in it. Does it open quickly? If not, then I'm wondering if you have network lag.
- Is there any lag with planning a normal numeric value? You may have to optimize the calculations. You can also tell by how long it takes to rollback the model if you make a syntax error. Some people call this toaster time, but it's the DAG calculation paths are burdened.
- Lastly, if you try to create a new model with only that list in it. and drop it on the New UX, do you still get the lag?
Only other suggestion I can think of is to go down the list subset route but that won't help if you've got network lag.
Adding super pros @Misbah , @rob_marshall as they may have some good advice.1
Thank you, Jared! I will give these a try. I appreciate the help!
One detail I forgot to add is that this model is still in the Old UX. We would migrate to the New UX but it's still missing some key functionality, such as pivoting.
Ah, good to know. Pivoting was just released for pages. Same functionality now as worksheets. FYI.1
A couple of questions:
- how many line items do you have in the module?
- Do you have any that are doing a finditem() on a large list?
- For a test, create a new line item, with the same format in another module, do you experience the same symptoms? The reason it would be different is due to the downstream calcs because the new line item in the new module would have none.
Hope this helps,
@rob_marshall Thank you! I think there is just too much going on in the module. I tested the same line item in a separate module and didn't have the issue.
The module has 292 line items. I know that goes against best practices, but this model was designed and built (for the most part) by a solution architect from Anaplan. It's a Headcount model, so it is tuff to separate out some of the input line items from the main Position/Employee modules for workflow reasons. The build quality is very good, but I suppose its one weakness is the two giant modules.
I removed the finditems as a test and it had little impact. I think I'll just put these input line items in a separate module.
Holy ****, 292 line items! That is not good, but here is a trick you might want to try. I am assuming not all of those line items are inputs, gosh I hope not! Any line items that are absolutely needed for the dashboard, information the user sees, keep that in this module. Then, create a new module, with the same dimensionality, and store the calc'd line items in that, while using the original module for the inputs of the calcs (if needed). What this does is separate out all of the processing in one module.
Or, you could do it the other way around, which might be easier (create an input module with the same dimensionality, and all "necessary" line items, information the users sees). Then, use this module as the inputs for the "original" module for the calcs. This way, you won't have to change any downstream calcs.
Hope this helps,
This is really helpful! Thank you, Rob.
I always enjoy learning a little bit more about how Anaplan processes things. I'm familiar with the concept of time complexity, but it is a little opaque in Anaplan. There are a lot of great heuristics on the Anaplan community, such as try to keep modules to 50 line items or less. However, it is a little harder to come by the "why" behind it all. I appreciate the insights!0