@Freddy That's a lot of rows you retrieve in a single call! If you can't (or don't want to) limit the number of rows (Pagination), your options are limited. You might have checked these already, but I can think of the following things:

• First of all, we don't do a separate data call for the tree view, meaning we retrieve all columns to which the user has access on the Subject. This could cause the call Size to be unnecessarily large and as a result negatively impact the Timing (check Developer Tools > Network tab to check the Size of the call. Then select the Call and check the Timing tab to review what causes the delay. Perhaps the Content Download duration is the bottleneck).
• If retrieving all rows is not necessary for other Screen Components and the call Size is indeed the major cause, you could consider creating a dedicated View for the tree.
• If the Size and Time of the Network call are not as high as the experienced ‘sluggishness’, please use a timer to see how long it takes from opening the relevant tab to building up the tree in it's entirety in the GUI. It might be that the Universal GUI needs a lot of time to build up the screen (this is not reflected in the Network and Timing tabs). If you're not on the latest Universal GUI (2024.3.10), please do try and test with that one too, as we tried to eliminate as many unnecessary Renders as possible.

Please let me know the results!

If you have large amount of items in the tree,  it will fetch the first X amount, based on pagination an it doesn't fetch the rest. So you either fetch everything or a part, and of course fetching only a part doestnt make much sense. 

if the pagination would be per level, this would make more sense. So everyone you open the tree he would look for the next X items. 
 

If reduced the amount of items to 6200, and opening the tree takes about 6-8 seconds.

Every item you click after that takes basically the same amount of time to load the details.

I know limiting call results is the first answer, but let's say it's not possible nor wanted. 

I'm just trying to understand the buttons we can turn to have optimal performance. So I have already boosted the available memory on Indicium and the DB to rule out this as a prime factor. 

• So the first call that gets the tree takes 400ms  and server timings say that 370ms is the query, which makes sense.. it's quite some rows. 
• Then a context() is fired. Timing says 400ms waiting on server response.
  • Timing: 390ms GetRowForKeySegment (what does this mean?)
• Next 2 detail calls (1 for detail + 1 count)
  • Timing: 500ms each with server timing 437ms GetRowForKeySegment and 100ms OpenDatabaseConnection (first.. second db-conn 0.8ms)
  • Timings are similar between the 2 calls
• Next a call to get the root node image for the tree:
  • 730ms waiting for server; 380 to get file record and 325 to get file stream. 

There is some increased limited stalling up to 1.5 ms .. 

However, the 'sluggish' thing happens when I then click on a random parent node (tree opens 1 level open). When in the GUI I click on the 5th node..  nothing happens. I'm assuming this refers to the initial connection/ssl  connection start timings, which are not present at the first call. 

Intermediate badge() calls take about 400ms .. also with GetRowforKeySegment 460ms…  what is this and why is it persistently high after the first call? 

if the pagination would be per level, this would make more sense. So everyone you open the tree he would look for the next X items. 

@tiago Pagination and Grouping are no good friends in the Universal GUI indeed. The combined behavior is not intuitive and not really workable. We have this on our radar (it’s an existing TCP ticket) and we are indeed considering a fix along the lines you describe. But properly fixing this is quite a challenge and not the highest of priorities at the moment.

@Freddy I am actually thinking along with you, so you don’t need to reduce the nr of rows. My suggestions are about optimizing the call in terms of columns retrieval, to limit that to what’s necessary for the tree only.

• Timing: 390ms GetRowForKeySegment (what does this mean?)

@Freddy this is the query based on the Primary Key to retrieve information about the selected record. We see these kind of response times more often with Views, which is too high. Make sure to check your PK and Indexes setup in order to improve this Query performance. This explains all ~400ms calls for Badge / Context / Details as they all run over the Primary Keys.

I have been playing around with a large Tree and was actually positively surprised about how well it performs in the GUI.

I don’t really understand your explanation of ‘sluggish’ experience. With the information at hand, there is not much more we can help you with. 

If you truly think there is something the GUI could do better, feel free to raise a TCP and include a clear screen recording of your experience, together with a HAR for that recording.

Also, I’m still curious what Use Case you’re serving that requires so many records to be loaded at once and if there’s really no alternative to it.

How about starting empty with filter for example, or opening a Task from the menu that helps the user make a selection based on which you can do a filtered Open Document with the Tree?

@Arie V the business case is Brazil. In this case a bank that operates national, just to have some notion there are 5568 municipalities, including subdivisions there are over 10,670 districts.  If there is a branch per district and only 3 organization entities per branch then you are already over 30000 nodes. This case I didn't een consider matrix organizations et cetera. 

Don't get me wrong that we should always strive to minimize data sets and such.. but in a country with 212.6 million people and over 15 million businesses..  28.900 is not even that much. 

That said, I think @tiago said it correctly, we shouldn't want to load the tree upfront, but rather per level. Because the 'tree' doesn't get smaller..  But it is a waste of data to load the full tree, whilst this appear to happen again whenever you open up an extra level. 

As for the data, we already load the minimal amount. Just the root, parent, child, name and an icon (which is still empty for all)

Hi @Freddy,

The 5568 municipalities are spread out over 26 states right? Would it solve your problem to have a parent table for the states so you are always only looking at the municipalities of a state? The highest amount of municipalities you then get for the state with the most municipalities is 853.

I'm all for optimizing performance where possible, but having 30000 nodes in the tree will always result in a degraded performance experience.

Kind regards,
Leroy Witteveen

Hi @Leroy Witteveen 

The example was hypothetical, and it would not solve my problem. The point with your suggestion is creating a parent subject and thus a distinctly different setup. In this case, I don't know what my top levels are, because it's configurable by the users. This would imply that I would have to detect the first levels, put them (and sync them with every change) in a separate parent object. 

The problem isn't so much the 30000 items in the full tree in my opinion, but more that it becomes a problem when you load the full tree at once. So if I don't want parent subjects, we should explore alternative loading solutions. 

Just looking at it, first load should be be the amount of levels define to be shown (arguably +1 for to pre-load the first expandable level). Then this is your base. Subsequently you want the base + the children of the parent node that you expand (level + maybe 1 level to pre-load).  In this case you wouldn't need to load all elements (not considering choosing to open all levels to be set in the SF, or the user clickiing on expand all nodes). 

So, I think the evolution of the tree is to have tree-pagination, and I think it works like described.  Base load is the tree with the amount of levels defined in the SF (arguably + 1 level).. and then the user dictates what will be loaded next (base + chosen node to open). 

Hi @Freddy,

As Arie mentioned, there is already a TCP ticket present regarding the combined behavior of pagination and grouping. You can submit an additional ticket if the GUI does not meet your needs in another way.

Your suggestion for tree-pagination, loading the tree per level instead of upfront, seems like an idea you could submit to this Community.

Are there any aspects within this topic that have not been covered with this reply?

Your suggestion for tree-pagination, loading the tree per level instead of upfront, seems like an idea you could submit to this Community.

@Jeroen van den Belt @Freddy No need to raise an Idea for this, this is a very likely solution to the TCP ticket (although not a high priority at the moment).