Well, when someone wants to make a webcall like every 60 seconds and fusses about a two second delay that it takes to make that call, i naturally assumed this was a timing critical thing. That's why i posted that it might be useful to put the timing critical code into a separate process and not mix it with other code that could introduce "random" delays.

While interprocess communication on a single computer has it's own delays and caveats, these delays are usually much shorter and more predictable that calls to external services. For my example code, i assumed that OP wanted to start the external call at a specific interval. There is no way to predict how long that takes and when the server is seeing it (lost packets in handshake and so forth), but that is another matter entirely.

Another thing to consider is that the code outside the webcall also gets delayed while the webcall is in progress. The $pricing thing let's me to believe this is some kind of trading bot thing, which i assume wants to check for the new price at the start of every minute, just when the trading plattform releases it.

Splitting the delay from the webcall into a separate process would allow the rest of the bot to run at full speed the whole time, except for the minimal delay it takes to regularly check if a new price arrived through a Unix Domain Socket or pipe.

I'm probably overthinking this, but hey, that's what i do best 8-)