busyloop / lolcat

Rainbows and unicorns!

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Very long execution time on initial call after system restart

Spiral90210 opened this issue · comments

Noticed that every time I restarted my laptop (mac, 10.14.6, system ruby), on initially opening my terminal (zsh) there was a very long delay before I had control. Subsequent new shells did not exhibit this behaviour. For info, lolcat is invoked as the last action of my rc file, and was installed via homebrew.

I profiled the startup, and found that it took 18 seconds for the initial lolcat call, an order of magnitude slower than anything else (time in microseconds):

18134485 /Users/me/.rcfile:195> lolcat

Subsequent calls are much faster at .1s

140592 /Users/me/.rcfile:195> lolcat

It would seem that lolcat is doing something on the initial launch - but is it? If so, what is it doing, and can I disable it? It's super frustrating.

It's being used like

cowsay "hard coded text" | lolcat

The cowsay command is timed at 1.5ms, so it does initially appear to be lolcat.

commented

It sounds like you may be plagued by this new MacOS "feature": https://sigpipe.macromates.com/2020/macos-catalina-slow-by-design/

Unfortunately, as far as I know, there isn't anything that lolcat can do about it.
We have to wait and hope for Apple to provide a fix.

lolcat itself does not do anything special on first invocation
vs subsequent ones (it doesn't store any state or data so it
doesn't even know how many times it has run before).

commented

Actually there might be a possible workaround, albeit a clumsy one:
You could try creating a dummy script that runs lolcat --help and
put that in your startup items.

In theory this dummy script may then (invisibly) perform
the slow initial call before you open the first terminal.

(I haven't tested this, YMMV)

On mojave, so it’s hopefully not that rubbish (I’ll double check the terminal is allowed dev permissions tomorrow).

Could be a million things really, appreciate you confirming it shouldn’t be doing anything itself, I’ll have to dive into it a bit more. Probably best to consider this closed in that case, but if I do find something I’ll let you know!

commented

Oh, yes, for Mojave I unfortunately don't have an idea at all.

Would be curious to hear if you find something.
(I imagine some kind of network call must be involved because
no local operation should take as long as 18 sec. If you have a
personal firewall like Little Snitch, perhaps that could shed some light)

commented

It sounds like you may be plagued by this new MacOS "feature": https://sigpipe.macromates.com/2020/macos-catalina-slow-by-design/

Unfortunately, as far as I know, there isn't anything that lolcat can do about it.
We have to wait and hope for Apple to provide a fix.

lolcat itself does not do anything special on first invocation
vs subsequent ones (it doesn't store any state or data so it
doesn't even know how many times it has run before).

My other commands are pretty fast, including figlet and ponysay. I basically pipe text through the 3 of them. If I drop lolcat, they run pretty fast.

Wow I wrote this a long time ago.

I never did get to the bottom of this, and actually stopped using lolcat - it seems disingenuous to leave this issue open without any kind of explaination, but I am unable to find one. I will say that it does seem very important now to ensure that your terminal emulator and anything that can spawn a shell (e.g. vs code/jetbrains ide's, things like that) are marked as "Developer Tools" in Preferences -> Security & Provacy -> Privacy. I believe that option may only appear if xcode (maybe just dev tools?) is installed as well. This drastically reduced 'first run' of things like new script files and compiled (golang) binaries for me.

Sorry I couldn't do any better.