Re: ReactOS: stack vs heap

[Alexei Podtelezhnikov]

Hi Ben,

I will try the dynamic heap allocations for the rendering buffer. This
might be the largest of them, I think. In addition, this should help
with the rendering speed when rendering complex shapes like
https://fonts.google.com/specimen/Cabin+Sketch. Currently, FreeType
makes several attempts until a sub-band can fit into a static stack
buffer. We should be able to fit it into a dynamic buffer easily. I
wonder if CabinSketch should be about as complex as we can tolerate
and refuse anything much more complex than this. A lot of time-outs
will be resolved...

Alexei




On Thu, Aug 31, 2023 at 7:40 AM Ben Wagner <bungeman@gmail.com> wrote:
>
> I've been meaning for a long time to propose something like this. One (or 
> more) of those stacks is bigger than 50KB. While most desktop apps have 
> threads with large stacks (~xMBs) there are users that run many threads in 
> one process and force the stack size of the threads to be small (~xxKBs) to 
> enforce small stacks so that the stack memory stays hot. On macOS secondary 
> threads are also pretty small at 512KB. Calls to FreeType often happen deep 
> in some application layout code which often is taking up a bunch of stack 
> frames, so a sudden deep 50KB stack frame can be too big.
>
> In any event, I have seen these really big stack frames be an issue in 
> practice. I've so far generally been able to get around this issue but it 
> would be nice to not need the work arounds. I think a lot of people would be 
> happy if FreeType reduced the size of these stack frames.
>
> On Wed, Aug 30, 2023, 11:20 PM Alexei Podtelezhnikov <apodtele@gmail.com> 
> wrote:
>>
>> Hi folks,
>>
>> Found this patch from ReactOS
>> https://git.reactos.org/?p=reactos.git;a=blob;f=sdk/lib/3rdparty/freetype/freetype_ros.diff
>>
>> Do you understand why they are so averse to large stack allocations?
>>
>> Thanks,
>> Alexei
>>


--
Alexei A. Podtelezhnikov, PhD