HaikuDepot search feels less snappy

[humdinger]

Try this:

• Go to "All packages"
• Enter "colors" in the search box

--> The list gets filtered while you type. Feels snappy enough.

• Now select the search term (ALT+A if the box still has focus) and press DEL to empty the search box and reset the filter.

-->It takes a second for the "colors" to disappear and list to get unfiltered. Feels very un-Haiku sluggish.

Even worse when your cursor is at the end of the search term and you repeatedly hit BACKSPACE.

It seems like the search box entry and filtering is synchronous, i.e. after each letter we need to wait for the list to finish filtering.

I think it used to work differently in the past. At least I remember it being very responsive.

[apl-haiku]

Hi @humdinger; Yes, you are right it was faster in the past but I think a large part of that was because there were significantly less packages in play. See the attached image of the cumulative packages over time 2014-2023. Reminder in case I need it again...

WITH x AS (SELECT TO_CHAR(p.create_timestamp, 'YYYY') AS year, COUNT(p.id) AS pkgs_created
           FROM haikudepot.pkg p
           WHERE p.create_timestamp < '2024-01-01'
           GROUP BY TO_CHAR(p.create_timestamp, 'YYYY')
           ORDER BY TO_CHAR(p.create_timestamp, 'YYYY') ASC)
SELECT year, SUM(pkgs_created) OVER (ORDER BY year ASC ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
FROM x

The architecture inside the desktop application is clever; it is strongly "reactive" in that it updates UI as the data inside HD changes. This architecture worked very well and looked good when there were hundreds of packages but now there are more like 20,000 packages it is starting to be less ideal and hence why it appears to be slow.

What I want to do is to change the application data architecture so that it does operations like the initial load and search filters as one-hit bulk operations rather than have the UI react to each and every change. To do this, I need to change the data and locking model inside the application. I'm slowly preparing the model for this but it is taking a lot of elapsed time.

BColumnListView is also missing methods for bulk operations such as ReplaceAllRows(..) as this will be required.

With the search specifically there also needs to be a de-bounce so that it does not respond to every key-press. This could probably be progressed sooner.

[apl-haiku]

A graph of the cumulative packages over time 2014-2023.

[humdinger]

Glad you're looking into the overall architecture, too.

With the search specifically there also needs to be a de-bounce so that it does not respond to every key-press. This could probably be progressed sooner.

I agree, this could be a first focus, because if the direct reaction to user input is delayed, it feels worse than if one can suspect slow loading from the server etc.

Speaking of which - and maybe this should go into a separate ticket - after starting HaikuDepot, it often looks like the app twiddles its thumbs while "Syncronizing package data...". I have ActivityMonitor show network send/receive and have an eye on Pulse, and for long stretches there's neither network traffic nor much cpu activity. Are we sure HaikuDepot isn't taking a nap? :)

[apl-haiku]

Are we sure HaikuDepot isn't taking a nap? :)

From what I have seen this is often due to lock contention.

(Slow to reply)