Diego Biurrun <[email protected]> writes:
> On Sat, Jan 21, 2012 at 06:28:33PM +0000, Måns Rullgård wrote:
>> Diego Biurrun <[email protected]> writes:
>> > On Fri, Jan 20, 2012 at 02:24:18PM -0800, Luca Barbato wrote:
>> >> On 20/01/12 13:49, Martin Storsjö wrote:
>> >> > On Fri, 20 Jan 2012, Luca Barbato wrote:
>> >> >
>> >> >> On 20/01/12 11:00, Martin Storsjö wrote:
>> >> >>> Originally, sizeof(struct MOVIentry) was 48, after the reordering,
>> >> >>> it is 40 in my build configuration.
>> >> >>>
>> >> >>> When writing really long mov/mp4 files, this can make a difference
>> >> >>> - this saves a bit over 2 MB of memory per hour of video (down to
>> >> >>> 10.3 MB per hour from 12.3 MB per hour initially) for a video with
>> >> >>> 75 packets per second - 25 fps + 50 audio packets (which is the
>> >> >>> case for AMR audio).
>> >> >>> ---
>> >> >>
>> >> >> Ok, I guess. Is there around something in dwarves to point structures
>> >> >> that could require less memory once reordered.
>> >> >
>> >> > Could you rephrase the second sentence - I don't really understand what
>> >> > it says.
>> >>
>> >> I was hurrying away... I meant that the dwarves tool should have a mean
>> >> to provide this information, if we want to try to brush away some memory.
>> >
>> > Go right ahead :)
>> >
>> > I remember that Mans once mentioned that the structures in the Vorbis
>> > decoder could benefit from tighter packing.
>>
>> That goes for a lot of structs.
>
> So what does a poor uninitiated soul like myself have to read to know
> how to pack tightly or tighter and fix or improve such cases?
If you know the struct layout rules, it's simple. Unless otherwise
specified, struct members are naturally aligned, e.g. a member of type
int is 4-byte aligned. Pointers are either 4 or 8 bytes. For layout
optimisation, assume 8 bytes since this is more restrictive.
The upshot is that packing is improved by grouping members of the same
size together, thus avoiding holes. Consider this:
struct {
char a;
int b;
char c;
};
The int here must be 4-byte aligned, so there will be 3 bytes of padding
following both of the char members, for a total size of 12 bytes. The
packing is improved by ordering like this instead:
struct {
char a;
char c;
int b;
};
Now there is no need for padding following the 'a' member since 'c' does
not need more alignment. There are still 2 bytes of padding between 'c'
and 'b', but the total size has shrunk to 8 bytes.
In large structs it can be beneficial to group related members close to
each other so they fall in the same cache line.
--
Måns Rullgård
[email protected]
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
