| Summary: | Info on slow startup with big playlist | ||
|---|---|---|---|
| Product: | [Applications] Elisa | Reporter: | george fb <georgefb899> |
| Component: | general | Assignee: | Matthieu Gallien <matthieu_gallien> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | nate |
| Priority: | NOR | ||
| Version First Reported In: | git-master | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | patch | ||
Created attachment 181779 [details] patch Been looking into improving the startup time and one thing that slows it down is the loop in `trackChanged`. When opening Elisa `enqueueRestoredEntries` is called, which loops over the playlist items of the last instance to restore them, each item is added to `mData` and `newEntryInList` is emitted. After some signal/slot jumps we end up in `trackChanged` where we loop over all items of `mData`. This causes the startup to increase the more items are in the playlist. One thing I thougt of is, in `enqueueRestoredEntries` when emitting `newEntryInList` also pass the index of item in `mData` so that we get that index in `trackChanged` thus avoiding the loop. I implemented this in a not-so-nice way and it improves startup by a lot. With this change, starting Elisa while restoring a playlist with 9K items took 2 seconds vs 15 seconds with the loop, that's the time until the playlist is usable. I opened this bug report because the code of `trackChanged` is very confusing and as I don't use Elisa I'm not particularly eager to spend more time on it, but still wanted to share this in case someone wants to look into this more.