Re: ReactOS: stack vs heap

What I said is wrong. But the blues array should be dynamically allocated,
and use a embedded version for small values. I'll work on it.

behdad
http://behdad.org/


On Mon, Sep 4, 2023 at 3:47 PM Behdad Esfahbod <[email protected]> wrote:

> On Mon, Sep 4, 2023 at 3:39 PM Behdad Esfahbod <[email protected]> wrote:
>
>> On Sat, Sep 2, 2023 at 12:31 AM Alexei Podtelezhnikov <[email protected]>
>> wrote:
>>
>>> >
>>> > Wanted to point out that compiling with gcc and adding
>>> "-stack-usage=2000" to get reports about stacks larger than 2000 bytes is
>>> probably the easiest way to track down large stacks at the moment. Note
>>> that af_cjk_metrics_init_widths (44480 bytes) and
>>> af_latin_metrics_init_widths (52992 bytes) are by far the largest.
>>> cf2_interpT2CharString (27520 bytes) is also surprisingly large. There are
>>> a few others like the rasterizer stacks that are between 10-20kb which one
>>> may also want to look into, but these have been less problematic on my
>>> experience (though that may have been due to the even larger stacks being
>>> allocated first). Just wanted to point out how to measure and that the
>>> rasterizer might not be the first place to look.
>>>
>>> That is surprisingly large. Someone should examine how much of it is
>>> actually used. The rendering pool of "visited cells" (pixels) is
>>> rather predictable for a given outline. That is why it is easy for me.
>>>
>>
>> I took a look at the autohinter one. The problem comes from:
>>
>> AF_LatinBlueRec  blues[AF_BLUE_STRINGSET_MAX];
>>
>> in struct  AF_LatinAxisRec_. The value of AF_BLUE_STRINGSET_MAX is ~260.
>>
>> My gut feeling is that that's a typo and should be:
>>
>>  AF_LatinBlueRec  blues[AF_BLUE_STRINGSET_MAX_LEN];
>>
>> where AF_BLUE_STRINGSET_MAX_LEN is 8. I haven't tested that.
>>
>
> Same thing in afcjk.h.
>
> I'm finding these using:
>
> $ make CPPFLAGS=-Wframe-larger-than=4096
>