Bug 468440 - Global Application shortcuts are slower than they could be
Summary: Global Application shortcuts are slower than they could be
Status: RESOLVED DOWNSTREAM
Alias: None
Product: frameworks-kglobalaccel
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.105.0
Platform: Other Linux
: NOR minor
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-04-12 23:12 UTC by Aleksey Kladov
Modified: 2023-04-26 12:54 UTC (History)
3 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 Aleksey Kladov 2023-04-12 23:12:55 UTC
SUMMARY

Global Application shortcuts (like `M+.` for emojier) add about 100ms delay in comparison to pinning the app in taskbar and using `Win+number` shortcut. That is, launching emojier with `M+.` is noticeably slower for me than pinning it and launching a new instance via `Win+1`

STEPS TO REPRODUCE
The delay is visible with a nacked eye, especially if you compare two kinds of shortcuts (xclock is a guinea pig). But I also confirmd that with time measurments using these two scripts

click.sh logs current time and uses ydotool to send `F4` shortcut

```
#!/bin/sh
date +%s.%N >> "/home/matklad/tmp/log.txt"
ydotool key 62:1 62:0
```

clock.sh logs current time

```
#!/bin/sh
date +%s.%N >> "/home/matklad/tmp/log.txt"
echo "\n" >>   "/home/matklad/tmp/log.txt"
```

If I bind F4 to global script shorcturt

```
[clock.sh.desktop]
_k_friendly_name=clock.sh
_launch=F4,none,/home/matklad/tmp/clock.sh
```

the result looks like this

```
1681339791.367891270
1681339791.488687436
\n
1681339792.845658459
1681339792.964949291
\n
1681339793.893609292
1681339794.015043447
```

That's about 120ms of delay between click.sh and clock.sh

If I find F4 to task manager

```
activate task manager entry 1
```

the result looks like this

```
1681340227.988185176
1681340228.001887438
\n
1681340229.466190483
1681340229.482717773
\n
1681340230.419816890
1681340230.437328642
```

about 20ms of delay, 100ms faster than the global shortcut

SOFTWARE/OS VERSIONS

Operating System: NixOS 23.05
KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.105.0
Qt Version: 5.15.8
Kernel Version: 6.2.10 (64-bit)
Graphics Platform: Wayland
Processors: 20 × 12th Gen Intel® Core™ i7-12700H
Memory: 62.5 GiB of RAM
Graphics Processor: Mesa Intel® Graphics

Related issue: https://bugs.kde.org/show_bug.cgi?id=468328
Comment 1 Nicolas Fella 2023-04-24 10:37:18 UTC
I haven't measured it, but https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/3 could help here since it cuts out an intermediate helper process
Comment 2 Aleksey Kladov 2023-04-24 11:01:01 UTC
>could help here since it cuts out an intermediate helper process

Aha, I think this helper process would explain 100% of the slowness I observe. On my system, spawning any plasma-related processes is very slow:

```
$  t kstart -h
<SNIP>
real 339.00ms
cpu  171.86ms (127.87ms user + 43.99ms sys)
rss  94.29mb
```

I fixed that dowstream (https://github.com/NixOS/nixpkgs/issues/225871), so I think it's fair to say that there's no "global shortcuts are slow" bug in plasma after all.

Still, getting rid of an intermediate process feels like a good idea regardless!
Comment 3 Nicolas Fella 2023-04-25 12:25:33 UTC
ah, that explains a lot.
Comment 4 Alexandre Pereira 2023-04-26 12:54:33 UTC
"so I think it's fair to say that there's no "global shortcuts are slow" bug in plasma after all."

Well, after your tip on using Meta+1, Meta+2 to launch apps, I started using that, and it "seems faster" than "global application shortcuts" even on Gentoo and Arch.

I say "seem faster" because timing kstart here gives around 70~80ms delay, so its hard to measure it really.

So at the end this will improve things :)

Thanks for reports this bug and fixing nixos side and Thanks KDE devs for improving KDE all the time! :)