Long lists causing performance problems

[maxwell8888]

Notes

Storing the full vector of ~90k MyStopTimes, using plain Strings and not Arc<String> in the AppData is not problem.

Filtering this list for a given trip_id on demand is also fine and doesn't produce any perceptable delay. Whether this is done by reassigning a new list using .iter().filter() in a AppDelegate, or using a FilteredList widget make no perceptible difference for stop_times.

So there is no performance problem with storing or filtering the lists, the performance problem seems to come entirely from creating the widgets which is why the routes list is the only one with a perceptible delay because the list is around ~1300 long of semi complex widgets. Where as stop_times is only ~30 items long. Widget complexity * length of list is the critical thing to manage.

Original problem

Currently, opening the Sao Paulo data with the app will cause it to crash. This is because the widget for a route is now more complex, containing lot's of Textbox's etc to allow updaing route attributes, and the number of routes in the SP dataset is around 1300, and the app becomes unusable at about 200 routes.

making inital data appears to only use around 200mb memory, implying the problem is with launching the app and creating widgets etc. This might not be right as 200mb seems quite low.

TLDR: Chosen solution is to keep the long list of routes but hide most of the widget controls behind dropdowns.

---

Storing all the routes and their attibute data in the app state doesn't seem to be a problem, only creating too many widgets for the data, which is convenient because the former would be a much harder problem to fix.

Two proposed solutions - choose solution 2

Solution 1

A simple solution would be to paginate long lists like routes. This is flexible and doesn't put any contrainsts on how complex the lists can be since we can reduce the length of each page until sufficient performance is achieved. The downside is that it would complicate syncing selections of items on the map with selections of items in the lists.

Solution 2

The second solution is to keep the long lists but reduce the complexity of the default route widget to the extent that displaying 1000's of them is still performant. This less flexible than the first solution but is easier to implemenent and is reasonable since the initial list of routes shouldn't display too much information or provide too much interaction anyway.
Arguably, very long lists don't provide a good user experience any because at a certain point they become too long to scroll manually with say a scroll wheel, and the scroll bar control becomes too small/sensitive to be used easily. However, the lists of routes should be the longest list displayed by the app and it is unlikely that other datasets will exceed SP's ~1300 (I believe London only has around 600, and larger areas will likely be spread across different agencies), and this number is perfectly usable.
In any case users will probably want some way of more easily finding a route they are interested anyway, rather than scrolling through and eyeballing 1300 cases, like selecting it from the map, or searching by name or some other criteria.
I'm uncertain whether widgets are dropped when they loose their visibility in an Either widget. If they don't then the app could end up crashing after the user has opened enough lists, even if opening a new list automatically closes the previous list.