yabai query taking ~8 seconds to return

[eraserhd]

I'm integrating with Kitty, and making a "kitten" to allow things connected to the tty to query their pixel position on the display. The kitten's code is very simple:

from kittens.tui.handler import result_handler
import subprocess
import json
import time

def main(args):
    pass

@result_handler(no_ui=True)
def handle_result(args, answer, target_window_id, boss):
    w = boss.window_id_map.get(target_window_id)
    if w is None:
        return ""
    a = time.time()
    os_window_id = w.child.environ.get("WINDOWID")
    if os_window_id is None:
        return ""
    b = time.time()
    data = json.loads(subprocess.check_output(["yabai", "-m", "query", "--windows", "--window", str(os_window_id)]))
    c = time.time()
    return str({'a': a, 'b': b, 'c': c, 'data': data["frame"]})

I get this output:

$ kitty @ kitten window_position.py
{'a': 1595951330.027246, 'b': 1595951330.027334, 'c': 1595951338.6383119, 'data': {'x': 2880.0, 'y': 704.0, 'w': 958.0, 'h': 699.0}}

During the delay, yabai commands hang and queue up (for example my skhd bindings to switch windows, which use yabai --focus, wait until the result returns).

If I replace the command with ls -l, it responds immediately. I isolated the JSON parsing, and that isn't taking any time.

I can't think of anything that causes this. I suspect the kitten runs detached from any terminal. I just tried to make it a "UI kitten", which gives it a tty, but that doesn't change anything.

[koekeishiya]

I have no idea how the python subprocess module is implemented so I cannot really help here.

Running from a CLI works fine and I also have personal projects that call yabai's query system using popen from C and that also finishes instantaneously.

~ time yabai -m query --windows --window 3278                                                                                                                                                                 
{
        "id":3278,
        "pid":1548,
        "app":"kitty",
        "title":"tmux",
        "frame":{
                "x":12.0000,
                "y":34.0000,
                "w":1416.0000,
                "h":854.0000
        },
        "level":0,
        "role":"AXWindow",
        "subrole":"AXStandardWindow",
        "movable":1,
        "resizable":1,
        "display":1,
        "space":1,
        "visible":1,
        "focused":1,
        "split":"none",
        "floating":0,
        "sticky":0,
        "minimized":0,
        "topmost":0,
        "opacity":1.0000,
        "shadow":0,
        "border":1,
        "stack-index":0,
        "zoom-parent":0,
        "zoom-fullscreen":0,
        "native-fullscreen":0
}
yabai -m query --windows --window 3278  0.01s user 0.00s system 78% cpu 0.011 total

[spolakh]

Not sure if it's related, but for me even the CLI execution delay varies wildly - at times it's instantaneous and at times it takes seconds to run (even when overall cpu usage is under 30%). Example: https://giphy.com/gifs/LkkNVInM528mPQLXJU

Makes querying pretty much unusable in shortcuts

Catalina, 10.15.6
Scripting addition enabled

[koekeishiya]

This could be because of reasons described in #599 / #600.
Basically the AX API is blocking and if the target application is slow to respond, that will ultimately be the bottleneck of how responsive yabai can be.

[slam]

FWIW, I ran into the same issue where yabai -m query --windows would be slow sometimes. When it was slow it was always about 8 seconds. I captured the output when it was fast vs slow, and here is a clue. (/tmp/x is fast, and /tmp/x2 is slow):

➜   diff /tmp/x /tmp/x2
69c69
< 	"title":"Activity Monitor (All Processes)",
---
> 	"title":"",
77,80c77,80
< 	"role":"AXWindow",
< 	"subrole":"AXStandardWindow",
< 	"movable":1,
< 	"resizable":1,
---
> 	"role":"",
> 	"subrole":"",
> 	"movable":0,
> 	"resizable":0,

I restarted Activity Monitor and the slowness went away.

[dvdbng]

I also ran into yabai query taking very long sometimes, I think some of the calls to retrieve the information block on the app so if you have one that is slow it takes forever.

I disabled everything I didn't need (which is everything except the window ID and the app name) and it's a lot faster even under load, compared it with original build and it went down from 2 seconds to 35ms (patch:
dvdbng@c4e3f0d)

Should really add an option to choose what is returning so that it's not waiting on thing that aren't necessary, add some caching, or make this calls in parallel if possible

[koekeishiya]

Caching maybe, but then how do you decide when the cache is out of date? These properties can only be polled, there is no notification system in the OS.

They cannot be threaded because the Apple API itself is blocking (takes a system wide mutex).

[koekeishiya]

Please follow up further discussion in #599, and #600. There is a reason they are still open.

[koekeishiya]

Added option to select which properties to return #2180