hein added a comment.
The idea and approach are good. But disk I/O in a UI hotpath is pretty scary. I do think a cache would be a good addition. In general I think libtm could use some improvements on its currently very coarse cache eviction scheme. It's mostly fine but there are some edge cases where we end up doing I/O on things we know we haven't changed. Unfortunately though improving that just means doing the legwork of going case-by-case and the complexity it invites ... i.e. a cache here. (Slightly unrelated: I have the beginnings of a patch set that uses KUserFeedback to gather telemetry on how often we use which identification means and why. I have this persistent feeling that we're falling through to the suboptimal/expensive code paths way more than we should currently, and there are probably minor changes to do "higher up in the file" to fix that. One is probably the neverending woes around normalizing for reverse DNS vs. plain .desktop file names. But in general I'd love for my system to be able go give me a trend curve for "Task Manager app identification expensiveness over time" to I can see when there's new regressions and/or changes in the app landscape.) REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D22506 To: broulik, #plasma, hein Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
