Is there any way to speed up startup?

[JumpIn-Git]

Since satty uses gtk, the startup is pretty slow, is there any way to speed it up? Im using hyprland (arch)

[gabm]

do you use the ppm image format? that should be faster (see README).

Apart from that, we might need to run the initial image reading from stdin in async .. you can try to implement that, if you want.

[JumpIn-Git]

do you use the ppm image format? that should be faster (see README).

Apart from that, we might need to run the initial image reading from stdin in async .. you can try to implement that, if you want.

I want to pipe images into satty, do you mean ppm is faster for loading in satty or saving the file

[gabm]

ppm is faster for loading, because it's uncompressed. png is using zip inside which is single threaded and may run a tiny bit slower.

As output format we only support png at this point.

[JumpIn-Git]

ppm is faster for loading, because it's uncompressed. png is using zip inside which is single threaded and may run a tiny bit slower.

As output format we only support png at this point.

i think it is slower because its also using libadwaita, is there any way to preload the latter/gtk?

[gabm]

I did some benchmarks w.r.t. intra-app startup and there the major factor was png decoding.

You claim that most of the startup time is loading of libadwaita. Might be. Can you back your claim?

[JumpIn-Git]

I did some benchmarks w.r.t. intra-app startup and there the major factor was png decoding.

You claim that most of the startup time is loading of libadwaita. Might be. Can you back your claim?

im just geussing, i mean you need to load gtk and libadwaita

[gabm]

yes you do but I'm not sure that this is bottleneck...

i also feel that satty could start up faster, but I'm not sure what is "slow". We need to investigate that first imho

[jficz]

I did some benchmarks w.r.t. intra-app startup and there the major factor was png decoding.

I did a naive "UX perception" test (started the app and counted in my head :) ) and came to the conclusion that png vs ppm makes almost imperceptible difference - the startup was pretty much the same in all test cases. The startup was, however, rather slow (~3s first start, consecutive starts within a short period of time ~1.5s), regardless of the format.

[RobertMueller2]

I think the speed up on the consecutive starts speaks for a caching effect. This can be observed with LD_DEBUG=statistics.

On my machine, it takes 0.6s before the first instruction (println in my case) in main is performed, 0.24s if it's a consecutive start.

Image loading is variable depending on image, obviously. That's e.g. 0.2s for small 600x400 image and 0.6s for a 10000x10000 noise image, both png, haven't compared ppm.

GUI starting takes another maybe 0.2s for me, although it is not that easy to get an exact measurement for that. Maybe need to combine this with timestamped strace and/or wayland debug log, of course both will slow it down.

I'll certainly analyse this further down the road, but it may take a while to get a grip on it.

My sentiment at the moment:

• caching - can be utilised for a minor speedup -- maybe we can figure out how to trigger it without actually opening an image, for session startup
• the rest of "before first line in main" could be further improved by a daemon. I'm not a fan of that idea, but it may help on slower machines. But somebody would have to implement it.
• the GUI part, similar dimension as the "rest of before line" in main, I don't think we'll be able to do much about that
• image size is a real wild card, obviously, and for bigger images it is the longest wait.
• GUI loading and image size can maybe be parallelised, if we can get the dimensions first. On slower machines, that might make more of a difference. But due to the former point, you might see a spinning wheel somewhere then.

[RobertMueller2]

To get a better understanding on this, would you people be able to provide output with --profile-startup added with #167?

date "+%s,%N" && LD_DEBUG=statistics  satty  --profile-startup <whatever parameters you normally use>

I suppose we're interested in both first and consecutive starts.

[postsolar]

satty-startup.txt

satty-startup-consecutive.txt

[MoonBurst]

output.txt
Admittedly, I'm not entirely sure what I'm doing with the command. But I ran it both with my normal grim tie ins, and on it's own. So hopefully that helps.

[gabm]

@MoonBurst unfortunately that didnt go well :/ In your case, the order of the arguments got mixed up.. pls try this

date +%s,%N; grim -t ppm - | LD_DEBUG=statistics satty -f - --profile-startup

Expected output looks something like this

-  date +%s,%N; grim -t ppm - | LD_DEBUG=statistics satty -f - --profile-startup
1746693607,478306854
    402083:	
    402083:	runtime linker statistics:
    402083:	 total startup time in dynamic loader: 161743 cycles
    402083:	           time needed for relocation: 4966 cycles (3.0%)
    402083:	                number of relocations: 103
    402083:	     number of relocations from cache: 7
    402083:	       number of relative relocations: 0
    402083:	          time needed to load objects: 69651 cycles (43.0%)
    402083:	
    402083:	runtime linker statistics:
    402083:	 total startup time in dynamic loader: 52720439 cycles
    402083:	           time needed for relocation: 35514489 cycles (67.3%)
    402083:	                number of relocations: 27799
    402083:	     number of relocations from cache: 2283
    402083:	       number of relative relocations: 90268
    402083:	          time needed to load objects: 17055684 cycles (32.3%)
startup timestamp was 1746693607.728922019 2025-40-08 11:40:07
   20 ms time elapsed: "configuration loaded"
   21 ms time elapsed: "loaded gl"
   21 ms time elapsed: "loading image"
   61 ms time elapsed: "image loaded, starting gui"
 1002 ms time elapsed: "app init end"
 3489 ms time elapsed: "gui show event"
 4438 ms time elapsed: "main loop idle"

Admittedly, I'm not entirely sure what I'm doing with the command

you are instructing your system and Satty to print information about its startup timings. We can deduce, where the startup time is spent and what to fix/optimise to guarantee a faster startup time.