Junction
Junction copied to clipboard
sonnyp
Slow startup time for some users
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
2-4 seconds seems like a lot.
There might be better ways to optimize.
What's your disk / CPU ?
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
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
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
- After closing Junction completely, what about
flatpak run re.sonny https://github.com? - What about https://aur.archlinux.org/packages/junction ? (Make sure to remove the flatpak first)
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.
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
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.
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.
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?
[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
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
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
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:
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.
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.
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.
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.
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.
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
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.
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
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
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
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
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)
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')
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
#!/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();