Bug 400364 - Task manager is too slow for managing large numbers of programs of the same type
Summary: Task manager is too slow for managing large numbers of programs of the same type
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Task Manager and Icons-Only Task Manager (show other bugs)
Version: 5.13.4
Platform: Other Linux
: VLO minor
Target Milestone: 1.0
Assignee: Eike Hein
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-27 13:21 UTC by martinlu
Modified: 2018-11-19 09:41 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description martinlu 2018-10-27 13:21:12 UTC
SUMMARY
Task manager is too slow for managing large numbers of programs of the same type. 

STEPS TO REPRODUCE

Use the default Plasma5 panel configuration in which tasks are shown on the task bar.

Create 50 instances of Konsole and try to switch to the lowest one in the menu being generated.


OBSERVED RESULT
It takes 2-3 seconds to build the menu that allows one to switch between Konsole instances (with 5GB RAM free).

EXPECTED RESULT
The menu should be built in less than 100ms or at least a factor of 20-30 compared to the current performance level.

SOFTWARE VERSIONS
KDE Plasma Version: 5.13.4
KDE Frameworks Version: 5.49.0
Qt Version: 5.11.1

ADDITIONAL INFORMATION
https://github.com/NixOS/nixpkgs/issues/49162

RECOMMENDED CHANGE IN PROCESS
Add performance test for this feature to your continuous integration solution such that this won't be a regression in the future. Specifically, I would like to see a graph with number of konsole sessions managed vs the time it takes to build up the menu and I would like to see a linear scaling in the graph.
Comment 1 David Edmundson 2018-10-29 21:53:53 UTC
It's a very niche case, however, on a quick glance there is room for improvement for large number of windows.

TaskList is a flow+repeater rather than a ListView, meaning we're instantiating N delegates at once rather than just the ones in the view.

More importantly updateView is called repeatedly during delegate insertion, rather than after initial (re)population. 

Solving the latter will probably be enough to close this.
Comment 2 Eike Hein 2018-11-19 09:41:58 UTC
Git commit ab26ebb18b74d8def8e653dc94516fa7da935a5c by Eike Hein.
Committed on 19/11/2018 at 09:40.
Pushed by hein into branch 'Plasma/5.12'.

Compress calls to `updateSize`

Summary:
Repeater+Flow has no reliable way to transactionize/batch insertion,
e.g. `Flow.positionCompleted` is useless in a function that can change
the Flow's size, and transition events like populated and similar
aren't available. Refactoring this to be a ListView isn't appealing
because it would mean the code loses the property of being reused for
both the bar and the popup, and therefore is well-tested already.

This brings down the number of `updateSize` calls when opening the
dialog for a group of five from five to one.

Reviewers: #plasma, davidedmundson

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D17006

M  +4    -4    applets/taskmanager/package/contents/ui/GroupDialog.qml
M  +1    -1    containments/desktop/package/contents/ui/FolderItemDelegate.qml

https://commits.kde.org/plasma-desktop/ab26ebb18b74d8def8e653dc94516fa7da935a5c