I've used the following scenario: I have opened a playlist containing N tracks already. Then I've added a DAAP client with 500 and 5000 tracks (containing tracks not already in the playlist). These 500 or 5000 tracks end up in the call to __refresh_changed_tracks.
Here are some numbers (Core2 Quad, 2.4 GHz): 500 tracks: N=2 old: 0.0015 sec new: 0.0016 sec N=10 old: 0.005 sec new: 0.0017 sec N=50 old: 0.027 new: 0.0021 sec N=150 old: 0.081 sec new: 0.0031 sec N=500 old: 0.27 sec new: 0.0067 sec 5000 tracks: N=2: old: 0.019 sec new: 0.021 sec N=10 old: 0.063 sec new: 0.021 sec N = 50 old: 0.341 sec new: 0.021sec N = 150 old: 1.25 sec new: 0.023 sec N = 500 old: 4,03 sec new: 0.028 sec Conclusions: - the new code is as least as fast as the old one if the playlist contains at least 2 items - creating the dictionary is linear in the number of tracks as expected - if the playlist contains at least 50 item, the new code is more than an order of magnitude faster - the speedup is only noticable if the number of tracks in the call is at least ~1000, but for lower numbers the new code is at least as fast as the old one -- Performance of __refresh_changed_tracks in playlist.py could be improved https://bugs.launchpad.net/bugs/492089 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
