Arvados

Reviewing arvados-workbench2|8fd2c92
Branch 17114-side-panel-tree-as-list

• The Tree component is used on several parts, including the “type filter selector” on DataExplorer UIs. As you can see on the attached screenshots, that selector is now broken because the user cannot select which kind of process or data collection to show.

I think it's really important to take measurements and build metrics so we can compare the before/after situation in an objetive manner and not by feeling.

I've taken the time to make these measurements. Here's the testing scenario:

• Cluster: ce8i5.arvadosapi.com
• Test project hierarchies (10000 projects each - you should be able to access them as I've shared them for read access):
  • Shallow hierarchy: ce8i5-j7d0g-e6a4l7kn7eu8um1 (100 projects with 100 subprojects each)
  • Deep hierarchy: ce8i5-j7d0g-93r09l3eydh39fp (10 projects with 10 subprojs with 10 subprojs with 10 subprojs each)
• Measurement: "Time to interactive" (TTI) as the time to load the page and it's consistently ready for user interaction. For this I used Chrome's DevTools Performance tab.
• Method: both master and branch versions were tested against the remote ce8i5 cluster using Chrome browser.

I'm attaching the result's screenshot and the original spreadsheet, but what I've seen is that the improvement although considerable, seems to be not enough:

9% time reduction in the deep tree case, and 30% in the shallow case.

Even with the 30% TTI reduction, the user has to wait for almost 15 seconds for the UI to stabilize, and that I think isn't a good enough user experience.

To recap yesterday's video chat about the topic:

• Renders got way down with the current branch fix: from 20k to 1k or something along those lines. (really good improvement!)
• The user currently suffering this issue is also probably still using an old arvados version with a bug that made the API server include the manifest_text field when returning collections as part of group/project contents. This clogs the HEAP and makes the browser go too much GC'ing, blocking the UI in the process.
• Daniel's development machine is resource constrained and that exacerbates the differences between the "before and after" code, taking a totally unusable version to a seemingly super fast (in comparison) experience. (at least IMO)

• After interacting with the UI, it's confirmed that the total used heap goes no more than ~90MB, this is really good.
• Once the first render happens (for example, by hitting the reload button), changing from project to project by clicking on the left side panel is "less slow" IMO, not yet snappy enough.
• I have a local arvbox instance with an hierarchy of 100 projects with 50 subprojects each and changing between projects takes me around 8-10 from click to total UI responsiveness (see attached Chrome DevTools Performance profile image, entire profile file also provided)

So, I would say that the current branch is ready to merge, but I'm not sure that the UI slowness when having too many projects is yet solved. I would advise to keep this ticket open while we wait for user feedback.