Slow startup time for some users

[bombaglad]

If I don't have the Junction app open already, there is a waiting period of about 2-4 seconds between clicking a link or file and the Junction popup appearing. Probably inevitable because it's a flatpak, current solution is to run the App and hide the window. Maybe add a background process that starts on boot?

Original title: Add background process / system tray icon

[sonnyp]

2-4 seconds seems like a lot.

There might be better ways to optimize.

What's your disk / CPU ?

[bombaglad]

It's a recent laptop - R7 4700U, NVMe SSD, no other significant programs runing I should also add, I'm on Manjaro, so I've installed it via Pamac

[sonnyp]

Can you open the app -> menu -> About -> System and share ?

[bombaglad]

Junction: version 1.3.0 programInvocationName /app/bin/re.sonny.Junction argv --gapplication-service cwd /home/matej datadir /app/share

Powered by: GJS 1.70.0 libadwaita 1.0.0 GTK 4.4.1 GLib 2.70.2 flatpak 1.12.2

Environment: OS Manjaro Linux $XDG_DATA_DIRS /app/share:/usr/share:/usr/share/runtime/share:/run/host/user-share:/run/host/share:/run/host/usr/share:/var/lib/flatpak/exports/share:/home/matej/.local/share/flatpak/exports/share $PATH /app/bin:/usr/bin $FLATPAK_ID re.sonny.Junction $XDG_SESSION_TYPE wayland

[sonnyp]

The flatpak takes less than a second to launch for me - with the same software. I don't really have an explanation why it would take so long on your system but I doubt it's related to flatpak.

Questions

1. After closing Junction completely, what about flatpak run re.sonny https://github.com ?
2. What about https://aur.archlinux.org/packages/junction ? (Make sure to remove the flatpak first)

[bombaglad]

Hm, weird.. running flatpak run re.sonny.Junction https://github.com takes up to 4 seconds, as does just simply launching it on Gnome. I'll have to get back to you on the second part tomorrow.

[sonnyp]

Before you test the aur version - something else that would be helpful is to compare

flatpak run re.sonny.Junction

with

flatpak run re.sonny.Junction https://github.com

[sonnyp]

Did you get a chance to look at this?

[bombaglad]

So, I think i found the reason - the CPU power state. With that set to powersave, it takes the mentioned 4 seconds. On any other power state, it takes between one and two seconds depending on the setting. Which is much better, but still not ideal, especially as this kind of app really needs to open immediately, so I'd still like to suggest some sort of background process. I love the responsiveness of the pop-up if the main window is open though!

I found no difference between just opening the app vs opening a website-link, and no difference between the flatpak and the AUR version.

[sonnyp]

I really think there is something going on with your system. Power state doesn't make a difference on mine. Junction opens pretty much instantly no matter what I do - even if I stress test all CPUs.

2 seconds is the time it takes to open Junction from SD card on the Pinephone Pro (Manjaro).

I recommend looking into it.

---

Sorry, I'm not adding a background mode unless I get multiple and reproducible data points.

In the future, Junction main window will be a drop zone meant to be left open so your workaround will work out well.

[sonnyp]

In https://github.com/sonnyp/Junction/commit/0fe671851e0aaf73a5df0a28e598abfd6cb387e0 - I've added an option to measure startup time. Can you please run the following

git clone https://github.com/sonnyp/Junction
cd Junction
bash
time ./re.sonny.Junction --terminate_after_init # twice

and share the first and second results?

[bombaglad]

[matej@**** Junction]$ time ./re.sonny.Junction --terminate_after_init

real    0m0,155s
user    0m0,114s
sys 0m0,030s
[matej@**** Junction]$ time ./re.sonny.Junction --terminate_after_init

real    0m0,150s
user    0m0,117s
sys 0m0,024s

[sonnyp]

Could you record and share a screen-cast where you reproduce the following

there is a waiting period of about 2-4 seconds between clicking a link or file and the Junction popup appearing.

Kooha can record mp4 which is accepted by Github, 60fps would be ideal https://github.com/SeaDve/Kooha#change-frames-per-second-to-60fps

[bombaglad]

https://user-images.githubusercontent.com/44273538/148663117-8f4e0470-ce68-434c-abeb-0b95ff869d71.mp4

here you go, sorry for the delay again. i've freshly installed manjaro again, have not messed around with almost anything so i really can't imagine something being wrong with the os. everything else is snappy aswell. sadly kooha does only 30fps apparently, but the observed time delay should be pretty clear

[sonicnkt]

Yeah i noticed the slow startup time as well with the flatpak, i allready switched to the AUR version before reading this and i definatly improved things but it is still a bit slow.

For example opening an image directly with eog is "instantly" but junction feels like it takes 500-1000 ms, tho the time measured don't really reflect this:

[nils@GNOME ~]$ time re.sonny.Junction --terminate_after_init xmpp_avatar.png 
real    0m0,040s
user    0m0,039s
sys 0m0,000s

I could probably live with this small delay because of the benefits but now that i tried it with it allready running in the background it is a lot nicer :smile:

[sonnyp]

Can you share this as well - out of curiosity

time flatpak run re.sonny.Junction --terminate_after_init xmpp_avatar.png 

---

--terminate_after_init only measures startup/init time - I wanted to see if it could have something to do with ostree / gjs but apparently not. There is room for improvement there as I don't bundle resources/sources but that's not going to make a perceptible difference if it takes 150ms or less right now.

As shown in https://github.com/sonnyp/Junction/issues/45#issuecomment-1008178244 - it is something else. Given the issue on the video is reproduced without a file being passed - I would start looking into that.

What would be helpful is for someone who can reproduce to add a bunch of console.time('foo') / console.timeEnd('foo') through the app code to find out what's taking so long.

Should be pretty straightforward. See https://github.com/sonnyp/Junction#development - happy to answer any question.

[sonicnkt]

Can you share this as well - out of curiosity

time flatpak run re.sonny.Junction --terminate_after_init xmpp_avatar.png 

Here you go:

[nils@GNOME ~]$ time flatpak run re.sonny.Junction --terminate_after_init xmpp_avatar.png
real    0m0,093s
user    0m0,013s
sys 0m0,004s

So subjectively i would say it takes twice as long as version from the AUR :) but nowhere near as long as in the video posted above. And i am also running Manjaro Gnome and my root drive is even a USB3 SATA-SSD because i was testing this distro/de combination before i wanted to move it to my internal NVME drive and replace my old setup.

[sonnyp]

Thanks

So subjectively i would say it takes twice as long as version from the AUR :)

If it's measured – it's not subjective :smiley:

In any case - 94ms is not our problem – specially if that's on USB3 😆

Someone will have to dig deeper to find out what it is.

[sonicnkt]

So subjectively i would say it takes twice as long as version from the AUR :)

If it's measured – it's not subjective smiley

Haha yeah :smile: Im running a Ryzen 5600X with XOrg (because NVIDIA) but this should definatly not be that much faster than @bombaglad.

[sonnyp]

t this should definatly not be that much faster than @bombaglad.

It's not - you reported 100ms and he gets 150ms. --terminate_after_init doesn't measure the problem. It occurs after.

[johnnyasantoss]

I've just found the project (great btw), installed and noticed that it takes a while to open (twice as much as my Firefox with hundreds of tabs). Also, I've found that the option --terminate_after_init does not measure exactly how long it takes to draw the window on my screen, so I've tried running it with time ... but kept holding esc (yeah, not really scientific - but should be enough), and it shows a time that is more realistic.

time flatpak run re.sonny.Junction --terminate_after_init
flatpak run re.sonny.Junction --terminate_after_init  0,04s user 0,01s system 22% cpu 0,226 total
# 226 ms to open

Opening without the option, but holding esc, to close as soon as the application is "active".

time flatpak run re.sonny.Junction
^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[^[
flatpak run re.sonny.Junction  0,02s user 0,02s system 1% cpu 2,373 total
# 2.3 secs to open

Running junction and looking at cpu time on htop (time+ column) also shows that bwrap is not the culprit here.

 PID△   TGID USER       PRI  NI  VIRT   RES   SHR S CPU% MEM%    DISK R/W   TIME+  Command
 257667  257667 johnny      20   0  2464   784   684 S  0.0  0.0    0.00 B/s  0:00.02 │  │     └─ bwrap --args 38 junction-wrapper
 257677  257677 johnny      20   0  2560  1296  1056 S  0.0  0.0    0.00 B/s  0:00.04 │  │        └─ bwrap --args 38 junction-wrapper
 257678  257678 johnny      20   0  7708  3788  3264 S  0.0  0.0    0.00 B/s  0:00.00 │  │           └─ /bin/sh /app/bin/junction-wrapper
 257679  257679 johnny      20   0 4471M  188M  109M S  0.0  1.4    0.00 B/s  0:02.34 │  │              └─ gjs -m /app/bin/re.sonny.Junction

So, what is exactly taking that long?

Running with an extra arg like https://github.com doesn't change the time to open that I'm seeing. It's always around 2.3s to open on my T495 Ryzen 7 3700U with NVMe ssd

[sonnyp]

So, what is exactly taking that long?

I explained here how to proceed https://github.com/sonnyp/Junction/issues/45#issuecomment-1017715160

Help welcome. It should be trivial to do with GNOME Builder and happy to answer any question.

[sonnyp]

In addition

@sonicnkt and @johnnyasantoss and anyone else experiences slow startup time please share the content of Menu -> About Junction -> System to see if there is a common factor

[sonicnkt]

Here you go:

Junction:
version 1.5.0
programInvocationName /usr/bin/re.sonny.Junction
argv --gapplication-service
cwd /home/nils
datadir /usr/share

Powered by:
GJS 1.70.0
libadwaita 1.0.1
GTK 4.6.0
GLib 2.70.2

Environment:
OS Manjaro Linux 
$XDG_DATA_DIRS /home/nils/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop
$PATH /home/nils/.local/bin:/usr/local/bin:/usr/bin:/var/lib/snapd/snap/bin:/usr/local/sbin:/var/lib/flatpak/exports/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
$FLATPAK_ID null
$XDG_CURRENT_DESKTOP GNOME
$XDG_SESSION_TYPE x11

Gnome: 41.3, Kernel: 5.15.16-1, NVIDIA: 495.46

[johnnyasantoss]

Linux - 5.14.21-2-MANJARO #1 SMP PREEMPT Sun Nov 21 22:43:47 UTC 2021 x86_64 GNU/Linux
Gnome 41.3; AMD Ryzen 7 pro 3700u w/ radeon vega mobile gfx;
---

Junction:
version 1.5.0
programInvocationName /app/bin/re.sonny.Junction
argv --gapplication-service
cwd /home/johnny
datadir /app/share

Powered by:
GJS 1.70.0
libadwaita 1.0.0
GTK 4.4.1
GLib 2.70.2
flatpak 1.12.3

Environment:
OS Manjaro Linux 
$XDG_DATA_DIRS /app/share:/usr/share:/usr/share/runtime/share:/run/host/user-share:/run/host/share:/run/host/usr/share:/var/lib/snapd/desktop:/var/lib/flatpak/exports/share:/home/johnny/.local/share/flatpak/exports/share
$PATH /app/bin:/usr/bin
$FLATPAK_ID re.sonny.Junction
$XDG_CURRENT_DESKTOP GNOME
$XDG_SESSION_TYPE x11

[sonnyp]

Do you have tons (like hundreds) of apps installed?

[johnnyasantoss]

Do you have tons (like hundreds) of apps installed?

If you are talking about .desktop files that can launch programs, yeah, i would say almost a hundred. A normal dev laptop, i think

[johnnyasantoss]

I tried running from source, and it seems to rebundle on every run. I'm not on my computer rn, but I can provide some logs tomorrow. (Didn't manage to fix it myself as I don't have much experience with gjs/gdk)

[sonnyp]

If you are talking about .desktop files that can launch programs, yeah, i would say almost a hundred. A normal dev laptop, i think

Nevermind, I was pretty tired yesterday and my comment doesn't make sense - it can't be related since the problem also appears when running Junction without any argument.

and it seems to rebundle on every run

Not sure what you mean or what's the problem? Make sure to use Builder 43

You can also try https://github.com/sonnyp/Junction#development

but I can provide some logs tomorrow.

Yeah it'd be very helpful if you could dig into what's taking so long with a bunch of console.time('foo') and console.timeEnd('foo')

[johnnyasantoss]

Not sure what you mean or what's the problem? Make sure to use Builder 43

I didn't have my laptop with me, so I called gjspack as bundler (couldn't remember the name) and adding timers (with console.time* methods) did show that it is the process that takes the longer (running from source is somehow way faster than the installed version).

$ johnny@thinkpad  ~/Repos/oss/Junction   main ±  ./re.sonny.Junction
Gjs-Console-Message: 15:26:42.016: imports: 0.006 ms
Gjs-Console-Message: 15:26:43.046: gjspack: 1029.582 ms
Gjs-Console-Message: 15:26:43.058: compile-schema: 12.149 ms
Gjs-Console-Message: 15:26:43.060: mainloop: 1.276 ms
Gjs-Console-Message: 15:26:43.060: start: 1044.898 ms

./re.sonny.Junction

```js #!/usr/bin/env -S gjs -m console.time('start'); console.time('imports'); // -*- mode: js; -*- globalThis.__DEV__ = true; import GLib from "gi://GLib"; import { programInvocationName } from "system"; import Gio from "gi://Gio"; import { build as gjspack } from "./troll/gjspack/src/gjspack.js"; console.timeEnd('imports'); const [filename] = GLib.filename_from_uri(import.meta.url); const dirname = GLib.path_get_dirname(filename); const GSETTINGS_SCHEMA_DIR = GLib.canonicalize_filename("./data", dirname); GLib.setenv("GSETTINGS_SCHEMA_DIR", GSETTINGS_SCHEMA_DIR, true); console.time('gjspack'); const { gresource_path, prefix } = gjspack({ appid: "re.sonny.Junction", entry: Gio.File.new_for_path("./src/main.js"), output: Gio.File.new_for_path("./src"), potfiles: Gio.File.new_for_path("./po/POTFILES"), }); console.timeEnd('gjspack'); const resource = Gio.resource_load(gresource_path); Gio.resources_register(resource); console.time('compile-schema'); const [, , stderr, status] = GLib.spawn_command_line_sync( `glib-compile-schemas --strict ${GSETTINGS_SCHEMA_DIR}`, ); if (status !== 0) { throw new Error(new TextDecoder().decode(stderr)); } console.timeEnd('compile-schema'); console.time('mainloop'); const loop = GLib.MainLoop.new(null, false); import(`resource://${prefix}/src/main.js`) .then(({ default: main }) => { loop.quit(); main([programInvocationName, ...ARGV], { version: "dev", datadir: ".", }); }) .catch(logError); console.timeEnd('mainloop'); console.timeEnd('start'); loop.run(); ```

[sonnyp]

@johnnyasantoss this stuff is irrelevant unfortunately—it doesn't happen on the end-user build, it's just development stuff only

You need to dig into main.js and its imports

[johnnyasantoss]

Isn't this the invocation script? Doesn't it get "bundled" into flatpak?

Running the flatpak executable, it seems to start with this file.

Or is there something in the build process that I'm missing?

How can I provide better logs?

[sonnyp]

Isn't this the invocation script? Doesn't it get "bundled" into flatpak?

src/bin.js is the entry point (it gets renamed to re.sonny.Juncton by src/meson.build)

[sonnyp]

According to https://github.com/NixOS/nixpkgs/issues/197908 looks like it's related to window transparency on Nvidia.

You could try setting the last value from 0.95 to 1 in https://github.com/sonnyp/Junction/blob/main/src/style.css#L16

[JoshMock]

EDIT: splitting this off into a separate issue https://github.com/sonnyp/Junction/issues/115

Experiencing this as well, but far more dramatically. Running re.sonny.Junction from the command line I get the following:

(re.sonny.Junction:21250): Gjs-WARNING **: 10:04:09.835: JS ERROR: TypeError: source is null
_init@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:750:1
@resource:///re/sonny/Junction/common.js:3:25
@file:///usr/bin/re.sonny.Junction:32:6

It never actually seems to launch the window, but the process doesn't exit either.

I'm running:

• Junction v1.6-2 via AUR
• Arch Linux 6.3.1-arch1-1
• i3 4.22 (2023-01-02)
• gjs 1.76.0
• gtk4 4.10.3-1
• glib2 2.76.2-1
• gnome-desktop 44.0-1
• xdg-desktop-portal-gnome 44.1-2
• libadwaita 1.3.2-1

[sonnyp]

@JoshMock it's a different issue - feel free to file another issue but it looks like you have a corrupted package or didn't reboot after update or something

[JoshMock]

Got #115 resolved, and links will open now, but startup time is still absurdly slow, which I was experiencing for a few days even before the Gio.js error:

❯ time re.sonny.Junction --terminate_after_init 
re.sonny.Junction --terminate_after_init  0.03s user 0.02s system 0% cpu 25.090 total

Desktop environment has above specs.

[sonnyp]

@JoshMock do you have an Nvidia GPU? https://github.com/sonnyp/Junction/issues/45#issuecomment-1529670123

[JoshMock]

@JoshMock do you have an Nvidia GPU? #45 (comment)

I do, and had already tried that fix. Same issue either way:

❯ time env WEBKIT_DISABLE_COMPOSITING_MODE=0 re.sonny.Junction --terminate_after_init
env WEBKIT_DISABLE_COMPOSITING_MODE=0 re.sonny.Junction --terminate_after_ini  0.03s user 0.01s system 0% cpu 25.069 total

❯ time env WEBKIT_DISABLE_COMPOSITING_MODE=1 re.sonny.Junction --terminate_after_init
env WEBKIT_DISABLE_COMPOSITING_MODE=1 re.sonny.Junction --terminate_after_ini  0.03s user 0.01s system 0% cpu 25.068 total

[sonnyp]

WEBKIT_DISABLE_COMPOSITING_MODE has no effect on Junction.

You could try setting the last value from 0.95 to 1 in main/src/style.css#L16

https://github.com/sonnyp/Junction/issues/45#issuecomment-1529670123

The next Junction release won't have transparency, that may should solve the issue for Nvidia users but if you want to make sure it'd be good to try what I suggested.

[Alaraajavamma]

I am using Junction with Pinephone and it sure helps because app selection is otherwise kind of scattered - while there are some workarounds Junction way is the best.

But with Pinephone Junction takes like 20-40 seconds to open xD. So with low-powered mobile-linux devices like Pinephone it would certainly help if you could keep Junction running in the background (like you can with some apps like Nheko and Telegram). Flatpak 1.7