Drop down selection lag

Hi all,

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?

Thanks,

Chris

Accepted answers

All comments

JaredDolich

@cbrookes

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.

cbrookes

Thank you, Jared! I will give these a try. I appreciate the help!

Best,

Chris

cbrookes

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.

Chris

JaredDolich

@cbrookes

Ah, good to know. Pivoting was just released for pages. Same functionality now as worksheets. FYI.

rob_marshall

@cbrookes

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

cbrookes

@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.

Chris

rob_marshall

@cbrookes

Holy Cow, 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,

Rob

cbrookes

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!

Quick Links

Can you help?

Unanswered questions

Create a Filter to show all the elements of that level based on selection in hierarchy
Hello Community members, Requirement Details: I have 5 levels of composite hierarchy list (A1, A2, A3, A4, A5). I have published a module in UX, Now the requirement is If user select a list member from A4 level in the context selector or Custom Filter I have to display all the list members under that A4 level. How can I…
import monthly data with months in columns
is there a way to import data with months in columns (usual excel table view)? I have to transform the data so there are rows to cover each period in the upload data form, but I am wondering if there is a better way to just import the data as is with the months in the columns. please let me know what you think. thank you,
Cloudworks Big Query Integration Fail
Hello, I am receiving an 'Anaplan Upload Failed' Status Description when testing my integration with a Big Query dataset. The integration imports data from BQ to our Anaplan model. No other details given in the error log. I suspect that Cloudworks is not even picking up the file but am not sure what we did wrong on the set…