Open jbriales opened 2 months ago
I always run with debug_output on and the performance is fine imo. It doesn't really amount to much, it mostly just logs events as they get processed.
If you build from source you can enable some profiling marks to get rudimentary timing info, but it is far from finished. I think the command was make install CLI_FLAGS=-DPROFILE=2
If you build from source you can enable some profiling marks to get rudimentary timing info, but it is far from finished. I think the command was
make install CLI_FLAGS=-DPROFILE=2
I'm interested on this. Built locally, but where do I find the timing info?
EDIT: Dumb question. Just needed to run directly as yabai -V
vs as a service, it seems.
@koekeishiya upon inspection of the timing info, it seems events are processed fast. However there is still latency/lag, and it seems it's because the processing of the next event only happens after a significant delay (~1s). Any ideas what's going on in the non-timed process between events?
For completeness, here is how the profiling via the Instruments tool looks like:
The different operations in yabai seem fast and lightweight, but they happen very far apart in time (1s in this case).
Simple Q: Is there any performance concern for having
debug_output on
by default in the config?My idea was to keep it on to be able to analyze logs and root-cause issues, vs enabling only after the issue, which maybe doesn't reproduce easily.
Or should I stick with just doing
yabai -m config debug_output on/off
manually?