-
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parallel processing repairing playlist #203
Conversation
8008b2f
to
d0a7d30
Compare
d0a7d30
to
4b65078
Compare
@touwys, can you review this PR? Expected result:
Please ignore the version number. |
Tested with a c 13-year-old Windows 7 x64 PC with a 4-core Intel Core i7-3770K CPU. These observations are not absolutely observed: Numerous playlists were submitted for test-repair. Those tested, contain any number of tracks from 19 up to 631. Result:
@Borewit: Great job — once again. 🏆 |
I am looking at the closest matches algorithm, looks like Jeremy optimized the algorithm for your PC @touwys: listFix/src/main/java/listfix/model/playlists/PlaylistEntry.java Lines 148 to 150 in 9a9c96a
🤣 |
Despite the funny comment, I removed that optimization and replaced that with parallel processing as well. Looking forward to hear if the find-closest-match algorithm runs faster as well @touwys. |
Is it ready to try out? I can only attend to it tomorrow.
I hope that it is as noticeable a difference as with finding the exact matches. What really counts though, is the accuracy of the matches, rather than the speed by which they are delivered. What I have seen so far, is that the current search algorithm is actually quite accurate for finding matching tracks where the broken ones form part of various artist compilations. Obviously, it's got more data available to process, in the file name of the broken track. So, one could probably retain that strength, and focus on massaging the algorithm where it tries to locate the tracks with very little data available in the filename. |
cd83680
to
5711af9
Compare
5711af9
to
ddc51bb
Compare
It's good thing you didn't test yet. I was not the smartest location to apply parallel processing, I adjust the processing keeping both parallel processing on Jeremy's memory optimization for now. For me the closest match runs very fast, so hard to notice a big difference. In this PR nothing changed from a functional point of view. So the accuracy has not been changed. On my Intel(R) Core(TM) i7-7800X CPU @ 3.50GHz, 6 cores (but 12 logical cores): Before this PR: After this PR: |
@Borewit : The advance in your results is clearly very impressive. Even if the huge difference in hardware makes a straightforward comparison of the results quite impossible, I easily recognised the improvement in my results. You've certainly done something special in this. To what extent do other variables such as, for e.g. the number of tracks in the media database, parsing of the track information by the search algorithm, etc. play a role in advancing the search speed?
Which build should I then download to use next, or should I wait for another? Please indicate. |
I expect no significant difference. With a background job which takes at least a few seconds, the advantage of parallel processing will likely by higher then a relative very short job, as result of a more optimal spread and the overhead being relatively smaller. Gaining small advantages resulting in more complex code, I am not much in favor of. In line with "Premature Optimization is the Root of All Evil". The code to optimization done for the "users with an ancient computer" is probably an example of that. It is almost asking for trouble. If you can please re-test the latest build |
@Borewit : listFix()-2.8.1.2 delivered some very interesting results Setup
ResultsTest 1
Test 2
CPU |
Changed repair playlist to parallel process.
On a CPU with at least 3 cores, on lengthy playlists, this should reduce the total processing time.
The playlist is no longer fixed in perfect sequence.