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)

[slema]

I have been experiencing this slowness on an old ThinkPad T60 (Core 2 Duo) and what annoyed me the most wasn't slow updates in the list but the fact that typing in the search box blocked so I just could not type while it was updating so it often blocked me in the middle of a word and as I typed one more letter it blocked me again.

Surely there must be a way for the search box to just update a variable for search string and not depend on anything in the rest of the UI to react ?

Edit: I should add that I am in Rio de Janeiro so anything related with ping times in servers in Europe is also very slow. Not sure what causes what.

[apl-haiku]

Surely there must be a way for the search box to just update a variable for search string and not depend on anything in the rest of the UI to react?

I don't really want to make piecemeal changes to try to tweak what's there because it's time consuming and fiddly. It needs an overhaul. My broad plan is;

• get the data model simplified right down and normalized
• try make the data models immutable or at least usable as immutable
• change the loading / filtering etc... to operate in bulk operations
• change the notification system and locking to operate in bulk operations
• get BColumnListView able to cope with bulk operations

Unfortunately this takes time as it is complex to do whilst keeping the application working properly and I don't have much spare time.

If you want to help, a good thing somebody else could do ahead of time to speed things up is to make BColumnListView have a method ReplaceAllRows(..) that's very fast.

[waddlesplash]

Debugger already has searchable ColumnListViews with lots of items and they are pretty fast. I don't think we need to adjust ColumnListView to have bulk operations at the moment.

[apl-haiku]

You may well be right @waddlesplash; it is hard to disentangle the threads but in sampling through debugger breakpoints (poor man's profiler) a lot of time goes into adding and removing rows in this class. I'll see a bit further down the road.

[waddlesplash]

Try using the regular profiler ("profile"), perhaps with Callgrind output and then QCachegrind (available in the repositories) to analyze the output.