>  I can prepare a more concrete estimation.
As an estimation, I plan to disable stack checks and set starting stack 
size high enough so that goroutines won't run off memory. Then I can run 
benchmark, for example sweet or etcd.

The minimum starting stack size will be determined from baseline benchmark 
runs, based on the observed stack usage. 
On Monday, 3 November 2025 at 14:13:49 UTC+3 Arseny Samoylov wrote:

> >  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/ce1379b6-9260-4662-bf6f-2310f8504c9en%40googlegroups.com.

Reply via email to