Have a feature request or suggestion? Post your idea here!

Post

2 Follower Folgen
0
Avatar

Major bugs in export functionality impacting performance

Hello, i'm using Rekordbox 5.2.3 on a Mac. As i work in software dev i'm interested in software performance. I've noticed some major issues with the export functionality of RB, which greatly impact export speed:

 

It seems when exporting a set of (already analyzed) tracks to an USB stick that already has RB files/db on it, RB is VERY SLOW when exporting. For comparison:

 

Taking the exported folder structure and copying it directly onto the stick takes about 1min20sec (working with 214MB in 71 "items", which are a combi of folders and files). 

When exporting the same files in RB it takes over 5 minutes. Also deleting the files on the stick takes a very long time (about 2 minutes).

I notice that RB has a LOT of threads open, more than any other application i have running (about 70 threads), and it also uses a lot of CPU, at least 25% and with exports around 30-40%.

I suspect that the programming of RB is very sub-optimal. I don't see any reason why it's eating 25% CPU when doing nothing/being idle. I don't see any reason why it needs to have almost 70 active threads at any moment. 

I believe there are some very dodgy processes going on when exporting, that are blocking each other. I also suspect that how RB handles the database updates, has a huge impact on performance. 

Finally, i believe this all can be fixed relatively easily by some experienced software developers. Optimising for non-blocking FS I/O and how to handle db-updates and FS updates is a known problem-space and can be done quiet well. 

I'm interested in hearing Pioneer's feedback on this. As it currently is RB doesn't feel like a professional tool, especially compared to the great hardware Pioneer is able to engineer and produce.

Kind regards, Olaf

sdj sjfd

Post ist für Kommentare geschlossen.

8 Kommentare

0
Avatar

As for performance when idle, my speculation is that it's because the application is "primed" and ready to go - data loaded to memory and constantly prepared to process the audio signal. Just like a gas-powered car, the engine is running (consuming fuel), waiting for input (accelerator > fuel > go). If the engine were off, you'd have to start it, shift it into gear, then press the accelerator - not very friendly on the response.

The engineers are unlikely to provide you with technical details, but I know they're constantly working to improve the function and performance of the software.

Pulse 0 Stimmen
Aktionen für Kommentare Permalink
0
Avatar

I’m totally aware that a lot of smaller files impact write performance. That’s not the issue here. This is exactly the reason why I tested with exactly the same amount of files and the same folder structures, same usb drive, same USB port etc. The native file system consistently achieves around 1min20sec, while rekordbox is much slower. A clean formatted usb drive starts out around the same speed in RB as on the FS, but then deteriorates to a multiple slower. Thats why my hunch is that some blocking behavior on file handling in combination with db updates is causing this. It’s very bad. Because it can be solved.
I don’t understand why you don’t acknowledge this. I’m a trained software engineer by profession, this would not pass our QA testing. The way it handles CPU while idle, the insane amount of threads, the quickly deteriorating export speeds, all a sure shot sign that something is structurally wrong in RB technical architecture. As said, these things can be fixed, and should be fixed l, when you want to be a professional company. Your software quality should be at the same level as the hardware. Looking forward to your reply! :)

sdj sjfd 0 Stimmen
Aktionen für Kommentare Permalink
0
Avatar

I appreciate your industry experience and passion for wanting to improve the product, however there's not much you or I could tell the engineers that would change the way their software is written or performs. You're welcome to file a ticket and make your comments known there, but again, I wouldn't expect much of a response.

Pulse 0 Stimmen
Aktionen für Kommentare Permalink
0
Avatar

Fair enough, tnx for the quick and honest replies!

sdj sjfd 0 Stimmen
Aktionen für Kommentare Permalink
0
Avatar

No worries -- I wish for improvements in every aspect of the software, nobody likes slow bloat-ware! I encourage you to file that ticket and hopefully someone will take note. ;)

Pulse 0 Stimmen
Aktionen für Kommentare Permalink
0
Avatar

For now I decided to use a Sandisk Extreme Go USB 3.1 64GB stick, format it in HFS+ format, and work with that. This seems to be the fastest option for now. The moment i detect slowness happening I format the stick again and export all playlists to the clean stick, this seems to be a good workaround. (NB could it be that you are testing RB only with specific brands and speeds of USB sticks?)

sdj sjfd 0 Stimmen
Aktionen für Kommentare Permalink
0
Avatar

See the video I posted at the top; I've tested with dozens of different sticks, most are the same result -- slow. That video only shows a handful, but my findings are that most "consumer grade" products (read: anything you could purchase at Staples or Best Buy) are the worst. Buy the most expensive ones you can afford, even if it means sacrificing capacity for a higher speed.

Pulse 0 Stimmen
Aktionen für Kommentare Permalink