Need for speed (v1.2 b165, 64bit, Windows)

I am sure Roon will respond. Biggest thing I see is:

Wondering why it is not using all your CPU/Cores?

@evand I’m currently running roon on Windows Server 2016 (64bit). I had the same performance issues on Windows 10 (64bit). I know that roon is much faster (instantaneous response) with smaller libraries (e.g. 5k tracks).

@dshore single core usage is probably due to “single threaded code” written by the roon team or in a library that they invoke to conduct their search. Unfortunately, that also means that it will not be trivial to solve. I’m keeping my fingers crossed that it is already being worked on or on the roadmap.

I wrote this post not to criticize the team who are doing a fantastic job improving roon all the time.
I hope that my example helps to identify an area for significant and meaningful improvement - search experience is a core capability.

I’ll leave a tag for @brian to follow up on this.

1 Like

Roon is definitely doing some things in this area. See this.


[quote=“mzbe, post:4, topic:16408”]@evand I’m currently running roon on Windows Server 2016 (64bit). I had the same performance issues on Windows 10 (64bit). I know that roon is much faster (instantaneous response) with smaller libraries (e.g. 5k tracks).
[/quote]your OS should yield the best performance that Roon can deliver as it’s running dotnet whereas under Linux and OSX it’s leveraging the mono codebase.

My library is also rather large albeit not quite as ginormous as yours. Sometimes browsing is instantaneous, sometimes it isn’t.

How did you record the video?

@evand: Navigation in roon is generally snappy when browsing via genre - artist - …
Search is the one soft spot right now - unfortunately, the other users in my family prefer search over browsing, despite my best efforts to retrain them. :wink:
I used SnagIt to record the video.

while my library is a modest 143,000 tracks, I am only running Win10Pro 64bit on an i5-6500 with 16GB ram and SSD - nothing special. search times are minimal at 1-2 seconds max if that! and library is on NAS via GB ethernet…no rocket science here. CPU is running at close to 0% for everything…music is playing in one roon ready (PS Audio DS Jr Bridge II) zone
No complaints here

Audio Analysis is FAST for both immediate and background options.

1 Like

i5-4690S @ 3.20GHz with 16GB ram and SSD here. At least once I’ve had to exercise restraint when tempted to toss an iPad Pro across the room due to non responsiveness. 143k tracks is not a large library where Roon is concerned.

My Roon database is 24GB, I suspect @mzbe’s database will be in the order of 34GB and yours to be ~10GB?

Looking forward to 1.3

closer to about <=6GB but that machine with the issue is a monster compared to my poor little i5-6500 is it not?

Most of the “database” size is in the images, which are stored as .jpgs on the filesystem in the %USERPROFILE%\AppData\Local\RoonServer\Database\Core - xxxxxxx[some ID] — images_1 folder.

The size of the “database” (.ldb) files (with the content metadata) is about 10% of the size of the images (in my case 2.3GB for broker_1.db vs. 18GB for images_1 (after compressing the images with JPEGmini to save some space - more than 5GB in my case).

4.5GB in my case for the images_1 folder … then again I am not having any issues. :stuck_out_tongue:

du -hs broker_1.db/ 1.8G broker_1.db/

du -hs images_1/ 24G images_1/

A friend of mine using Roon on an i3/8GB RAM Mac Mini experiences the same delays and lags I do, similar sized library.

I run a library of about 300k tracks and don’t get major lag. I found that the m.2 SSD made quite a bit of difference when I put the i5 NUC together. The read speed is very fast. I suspect that might improve startup; not 100% sure about ongoing use though. @brian will be able to advise.

I can’t recall the user but there was an example of striping 2xSSD on an i7 and getting good performance on a very large uber-library. Worth reading that user’s experiences.

1 Like

The startup/ refresh scan is no problem, it’s over very quickly.

OK…same here. Maybe we can check-in with @Brian w.r.t. preformance twaeks in 1.3 and if they specifically target the search code. I do see ~10s search from time to time.

I’m the developer at Roon working on this problem, I’m actually taking a break from writing search code to respond to this post.

The existing search code is slow because it’s very simple, it just looks at every artist/track/album/etc name in your collection in order and picks the ones that match your search. I’m working on an improved version that uses an index of all these names to avoid having to look at each one. I don’t have hard numbers to share at this point, but I expect this will make search feel “fast” even for very large libraries on modest computers.

Designing an index does everything we need it to without consuming huge amounts of memory for large libraries (remember that for 500k tracks we have probably 5 million things to search) is proving to be a difficult technical problem. Supporting the kind of wildcard searches we want (searching for “fields” should match “Strawberry Fields Forever”, for example) means I can’t use a simple index, and the complicated ones have a lot of difficult cases that all need to be rock solid before release.

I can see the light at the end of the tunnel now, and I expect this will ship with 1.3, but it has taken longer than I expected.

One thing that would help me is more test cases to run my code against. @mzbe, (or anyone else here with a particularly large library) could I get an Excel export of your artists/tracks/albums? I can send a PM with instructions on how to export what I need and upload a file someplace only Roon staff can get at it.


@ben what do you class as a particularly large library? Mines not huge, but small/med i guess.

The OP has 500k tracks, in my book that’s very large… I’d say large is > 200K tracks… but it’s all subjective.