> Most code does some data processing more > often than performing calls.
In my experience, there are still a lot of calls in real Go workloads. In particular, many indirect calls (through interfaces) that can't be inlined, so stack checks are still performed at runtime. > But how much of an increase? Most code does some data processing more > often than performing calls. Is the increase on a mix of real programs > 1%? 10%? More? Knowing this number is the most important thing to do > before going any further. I'd roughly speculate to have something like 3%-5% increase. But this is only a guess at this stage. My goal with this discussion is to understand whether such an idea would be considered worth exploring further - if so, I can prepare a more concrete estimation. On Monday, 3 November 2025 at 13:24:01 UTC+3 Jan Mercl wrote: > On Mon, Nov 3, 2025 at 10:25 AM Arseny Samoylov > <[email protected]> wrote: > > > **Drawbacks of this approach:** > > > > * Increased CPU usage due to frequent stack size checks and possible > reallocations > > The cost is non zero, so yes, the increase will be there. > > But how much of an increase? Most code does some data processing more > often than performing calls. Is the increase on a mix of real programs > 1%? 10%? More? Knowing this number is the most important thing to do > before going any further. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/ffc65ccf-902c-4709-a635-059603f8307dn%40googlegroups.com.
