Re: [dev] [st] font fallback

From: Charlie Kester <corky1951_AT_comcast.net>
Date: Sat, 05 Jan 2013 08:56:03 -0800

On 01/05/2013 07:33 AM, Charlie Kester wrote:
> On 01/05/2013 06:57 AM, Christoph Lohmann wrote:
>> Greetings.
>>
>> On Sat, 05 Jan 2013 15:57:21 +0100 Charlie
>> Kester<corky1951_AT_comcast.net> wrote:
>>> On 12/29/2012 12:20 AM, Kai Hendry wrote:
>>>> Initially I was worried that the newer version was somehow slower to
>>>> the version I was running before.
>>>
>>> Not slower, but definitely bigger. The stripped executable is now 16x
>>> the size of that from the 0.3 release -- thanks, no doubt, to these font
>>> caches, which are implemented as static arrays.
>>
>> That’s only partially true. The array is adding 48k, which another patch
>> series will reduce. Most of the additional memory usage is due to the
>> font handling. So the inability of font handling in X.org/Fontconfig is
>> the reason why too much has to be done over and over again. Yet another
>> abstraction layer would hide it but waste the same resources.
>
> Yes.
>
> I took a closer look at the stripped executables using objdump, and most
> of the increase is in the .rodata section:
>
> v0.3: 0cach (3,244)
> latest git: 16934h (92,468)
>
> But unless I'm mistaken, the static arrays go in the .data or .bss
> section (which also increased, but not by 16x.)
>
> So I must take back the allegation that the caches are the main culprit
> here.
>

I'm also seeing huge (> 20x) increases in the .eh_frame and
.eh_frame_hdr sections.

.data, on the other hand, increases slightly less than 10x.
(But I'd already dropped the Fontcache frc[] array back to 256 elements,
backing out the most recent change had which upped it to 2048. It was
only after seeing that reverting this had no noticeable effect on the
executable size that I started poking around with objdump.)

The contents of the .rodata section do seem to have a lot of
font-related stuff.

I have no idea what's going on with the .eh_frame* sections.

Hopefully these issues can be addressed and the size brought back under
control. One of the nice things about st 0.3 is that a stripped
executable is only 38k. That really helps convey the idea that it's a
simple, suckless terminal emulator.

Of course, some growth is expected as new features are added, but going
from 38k to 618k is hard to swallow.
Received on Sat Jan 05 2013 - 17:56:03 CET