Slow startup time for some users #45
Comments
|
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 |
|
Can you open the app -> menu -> About -> System and share ? |
|
Junction: Powered by: Environment: |
|
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
|
|
Hm, weird.. |
|
Before you test the aur version - something else that would be helpful is to compare with |
|
Did you get a chance to look at this? |
|
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 0fe6718 - 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 # twiceand share the first and second results? |
|
|
Could you record and share a screen-cast where you reproduce the following
Kooha can record mp4 which is accepted by Github, 60fps would be ideal https://github.com/SeaDve/Kooha#change-frames-per-second-to-60fps |
Kooha-01-09-2022-00-02-53.mp4here 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: 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 😄 |
|
Can you share this as well - out of curiosity
As shown in #45 (comment) - 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 Should be pretty straightforward. See https://github.com/sonnyp/Junction#development - happy to answer any question. |
Here you go: 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
If it's measured – it's not subjective 😃 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. |
Haha yeah 😄 |
It's not - you reported 100ms and he gets 150ms. |
|
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). Opening without the option, but holding Running junction and looking at cpu time on So, what is exactly taking that long? Running with an extra arg like |
I explained here how to proceed #45 (comment) 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 |
sonnyp
changed the title
|
Here you go: Gnome: 41.3, Kernel: 5.15.16-1, NVIDIA: 495.46 |
|
|
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) |
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.
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
Yeah it'd be very helpful if you could dig into what's taking so long with a bunch of |
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). ./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(); |
|
@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 |
|
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? |
|
|
According to NixOS/nixpkgs#197908 looks like it's related to window transparency on Nvidia. You could try setting the last value from |
|
EDIT: splitting this off into a separate issue #115 Experiencing this as well, but far more dramatically. Running It never actually seems to launch the window, but the process doesn't exit either. I'm running:
|
|
@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 |
|
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: Desktop environment has above specs. |
|
@JoshMock do you have an Nvidia GPU? #45 (comment) |
I do, and had already tried that fix. Same issue either way: |
|
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. |
|
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. |
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
The text was updated successfully, but these errors were encountered: