There are lots of things going on to improve search. It’s not one issue, and not all of the stuff that is impacting search is specific to search. I can elaborate on some of it…
In the most recent release, we rolled out a significant optimization for how the core handles out-of-library objects–search is a heavy consumer of this infrastructure. This fixed a primary cause of slow searches at that point in time and also reduced Roon’s background CPU usage in general.
Once the dust settled on that release (2-3 weeks ago), it enabled us to survey what remained. At that point, we discovered a root cause of 30-60s searches/timeouts, developed a fix last week, and rolled it out at the beginning of this week. As far as we can tell, that failure mode is over, and the next goal should be about getting currently 1-5second searches into the hundreds-of-milliseconds range.
The search index itself is adequately quick. Most of the time goes to either results processing, rights processing (determining which content you are able to see based on the TIDAL/Qobuz regions you are logged into), and formatting the results for transmission to the app. Search is one of the heaviest pages in the app and leans hard on a lot of infrastructure.
This infrastructure performs the same as it always has, but search has a much tighter responsiveness expectation than other pages, so it is forcing us to rethink a lot of how that old stuff was built. Much of this stuff was built long before we formed Roon, some as early as 2012, and at that time we were building a different product with a different set of goals. Re-building a lot of this is healthy and necessary, but not instantaneous.
Anyways–that infrastructure is about halfway through a ~6 month optimization project. The first half of the work is poised to roll out next week, and speeds up the most expensive steps by about 2x. The second half of the project is underway, and should yield a similar scale of improvement.
This project also enables us to deploy a more sophisticated worldwide caching system that will help reduce round-trip latency for everyone when loading data in Roon. This project is not search-specific–it will affect almost every screen in the app that loads data from our servers–but as one of our heaviest screens, search should benefit substantially.
We have another project in flight to multiply the capacity of our search backend by 2-3x and design a faster and better indexing process. This will help the speed of new releases getting into the search index. In parallel, we are also working on the latency of new releases showing up in Roon in general, both by coordinating with upstream providers, and by re-organizing some of our internal processes. The difference will be substantial once all of that work flows through. The larger-capacity search backend will also enable us to make the searches themselves more expensive–enabling us to re-attempt fuzzy matching, or otherwise improving the queries/results quality by spending more compute resources per search.
There are a collection of smaller projects related to search–building a better benchmark for search results quality, and tracking down a few minor bugs. This stuff is also in flight.
There is so much going on here that I’m sure I’m forgetting something…these infrastructure/backend projects take a lot of time and do not make for splashy product releases, but we have to do them. Roon has to get faster, and it has to do that while our user base continues to grow rapidly, and without breaking too much along the way. Not an easy problem, but one that has consumed a lot of our attention in the past few months.