Startup time

[torarnv]

I'm using this tool as a compliment to https://github.com/joa23/linear-cli, as the latter doesn't offer all the same features this tool does (and vise versa), but I notice the startup time of this tool is an order of magnitude longer:

# joa23/linear-cli
❯ time /opt/homebrew/opt/linear-cli/bin/linear -h >/dev/null
/opt/homebrew/opt/linear-cli/bin/linear -h > /dev/null  0.00s user 0.00s system 66% cpu 0.010 total

# schpet/linear-cli
❯ time /opt/homebrew/opt/linear/bin/linear -h >/dev/null
/opt/homebrew/opt/linear/bin/linear -h > /dev/null  0.13s user 0.02s system 99% cpu 0.155 total

I'm imagining that this matters (adds up) in repeated tool calls by Claude.

Any ideas why, and possible things that can improve things? Thanks!

[schpet]

i think deno is particularly slow here. i think porting it to bun would probably be the most performant option without rewriting it to a faster language like go or rust

[zhendalf]

Thanks for raising this, and thanks to @schpet for building the workflow that inspired a lot of our own work here.

Disclosure: I maintain linear-sdk-cli, a separate Bun-first implementation. Since a Bun port was suggested above, I wanted to mention that this is now available and includes a careful compatibility and migration path for schpet users.

As one local data point—not a universal benchmark—20 hyperfine runs on the same Apple Silicon machine averaged about 156 ms for schpet v2.5.0 --help and 85 ms for the Bun implementation, roughly 1.8× faster. It also reuses an existing Bun runtime instead of installing the standalone runtime-bearing executable for each tool.

It can be installed with bun add --global linear-sdk-cli; the collision-free lin alias lets both CLIs coexist. I am not suggesting this replaces improving startup here, only sharing it because it directly matches the Bun direction discussed in this issue.