Change History (6)
comment:1 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:3 by , 10 years ago
My recent work on HaikuDepot involves what additional package information is pulled from the web app when it concerns the list view. The thread which does this is started after the list is filled, see:
http://cgit.haiku-os.org/haiku/tree/src/apps/haikudepot/MainWindow.cpp#n618
My most recent work involves pulling more information, now asynchronously, when a package is clicked and selected.
So both of these work areas should not have any effect on startup time. The list of packages is growing however and maybe you mean the time it takes until the list is filled? You could test your theory of increased startup time by measuring an older version of HaikuDepot from before my recent changes on a current Haiku release that shows the same number of packages.
The time until the main window shows (what is usually considered the "startup" time) should be instant in any case and is independent of the number of packages.
comment:4 by , 10 years ago
I've just tested previous version and the time it takes HaikuDepot to populate the list is about 2 sec in both version. Sorry, looks like false alarm. Of course it would be nice if that was instant too. And while we're here, I wonder how does HaikuDepot scale with a growing number of packages, say, 10x times more?
comment:5 by , 10 years ago
The initial list is retrieved from the Package Kit, where it is cached AFAIK. I have not yet taken any performance measurements, where in the code it takes longer than expected. 2 seconds for 500 items sounds a bit long to mee, too.
In any case, I don't think the list is very useful as the first thing that HaikuDepot shows, especially not with 5000 entries. My idea was to show a selection of software that the user might be interested in. This is already implemented in the web app since a couple of days, with a "prominence" property that can be set by administrators for each package. This is orthogonal to the average user rating as a means to currate software. When a user starts HaikuDepot she would be greated by the "recommended apps" view, which would be based on the "prominence" setting, the user ratings, and it wouldn't show what is already installed. Of course, later the system could even tweak the featured apps based on user preferrence (how many other packages are installed from each category).
The featured apps view would only show a few packages, and probably organized as a grid. And it should of course be cached for fast startup. When the user searches, or switches categories, the view could switch to the list that is shown now. What do you think?
comment:6 by , 10 years ago
This sounds really nice! I'm really looking forward to seeing its first incarnation :)
Thanks for reporting! I've had it in the back of my head to make package information fetching asynchronous, it's now implemented and list selection is instant again (hrev47805).