> On Nov 7, 2019, at 2:02 PM, Linus Torvalds <torva...@linux-foundation.org> > wrote: > > On Thu, Nov 7, 2019 at 12:14 PM Berthold Stoeger > <bstoe...@mail.tuwien.ac.at> wrote: >> >> It doesn't have to. Just like you defined a proxy model on top of the >> DiveListModel, one could implement a proxy model on top of the tree model >> that >> "linearizes" it. > > Maybe we should do that in general, even for the desktop case. > > I don't think there is any major reason why the model should contain > all the dives. In many ways it would be much better if the model only > contains the *visible* dives, and we'd have a totally flat model, > where a trip (whether it's a collapsed header only, or the header for > a list of dives that has been exposed) is just a special model entry. > > That would mean that we'd handle collapsing and exposing trips by just > removing/inserting the dives in the trip into that flat model. > > IOW, get rid of the tree model entirely, and make that "proxy" model > be "the" model. > > Yes, yes, we have this very clever code to keep dives selected even > when they're not visible. It's a pain. it's probably not worth it. > > And it might be truly *lovely* for startup if we didn't populate the > whole model at all. For the git format, we could literally avoid even > parsing the dives that are in a collapsed trip and this not visible.
So we'd have a dive_table that isn't populated? That sounds entertaining. And some magic code that figures out when we need a dive and then quickly parses the information from git? But if loading XML we don't? And statistics functions would trigger fully populating the dive_table? Maybe it's the jet lag, but that sounds like a LOT of work and a lot of new corner cases - and I'm not 100% sure what we'd gain. I have only 640 dives in my dive list, so maybe that's not a good benchmark, but even in a very low end VM with a single core and not a lot of memory (2GB) I have never had issues with the Subsurface startup speed on the desktop. Our mobile startup speed is terrible, but that has other reasons. /D _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface