1259445 - Generate libav sin and cos tables at build time

Status: RESOLVED WONTFIX

(Core :: Web Audio, defect, P5)

Description

[Marco Castelluccio [:marco]]

https://github.com/libav/libav/blob/master/doc/tablegen.txt

See also bug 1254777 comment 4.

Comment 1

[Nicholas Nethercote [inactive]]

Are these tables always generated at runtime, or only on demand? If it's the latter, and the demand is infrequent, it might be worth keeping the runtime generation because they are in the .bss segment and so use only address space prior to generation.

Comment 2

[Nicholas Nethercote [inactive]]

Here are the sizes of all the tables, which in combination are 655,280 bytes(!)

> 0x20000 ff_cos_65536
> 0x20000 ff_sin_65536
> 0x10000 ff_cos_32768
> 0x10000 ff_cos_65536_fixed
> 0x10000 ff_sin_32768
> 0x8000  ff_cos_16384
> 0x8000  ff_cos_32768_fixed
> 0x8000  ff_sin_16384
> 0x4000  ff_cos_16384_fixed
> 0x4000  ff_cos_8192
> 0x4000  ff_sin_8192
> 0x2000  ff_cos_4096
> 0x2000  ff_cos_8192_fixed
> 0x2000  ff_sin_4096
> 0x1000  ff_cos_2048
> 0x1000  ff_cos_4096_fixed
> 0x1000  ff_sin_2048
> 0x800   ff_cos_1024
> 0x800   ff_cos_2048_fixed
> 0x800   ff_sin_1024
> 0x400   ff_cos_1024_fixed
> 0x400   ff_cos_512
> 0x400   ff_sin_512
> 0x200   ff_cos_256
> 0x200   ff_cos_512_fixed
> 0x200   ff_sin_256
> 0x100   ff_cos_128
> 0x100   ff_cos_256_fixed
> 0x100   ff_sin_128
> 0x80    ff_cos_128_fixed
> 0x80    ff_cos_64
> 0x80    ff_sin_64
> 0x40    ff_cos_32
> 0x40    ff_cos_64_fixed
> 0x40    ff_sin_32
> 0x20    ff_cos_16
> 0x20    ff_cos_32_fixed
> 0x20    ff_sin_16
> 0x10    ff_cos_16_fixed

The cos tables are initialized in ff_init_ff_cos_tabs(), and AFAICT that is not called automatically at start-up. Presumably it's only called on demand. So leaving them in .bss might be best.

I can't work out where the sin tables are initialized.

Comment 3

[Marco Castelluccio [:marco]]

(In reply to Nicholas Nethercote [:njn] from comment #2)
> The cos tables are initialized in ff_init_ff_cos_tabs(), and AFAICT that is
> not called automatically at start-up. Presumably it's only called on demand.
> So leaving them in .bss might be best.

Aren't they initialized here [1] and the sin ones here [2]?

'ff_init_ff_cos_tabs' initializes 'ff_cos_tabs', no?

Looks like 'ff_sin_tabs' is initialized here [3].

[1]: http://hg.mozilla.org/mozilla-central/file/a235bfcc8c41/media/libav/libavcodec/fft_template.c#l35
[2]: http://hg.mozilla.org/mozilla-central/file/a235bfcc8c41/media/libav/libavcodec/rdft.c#l31
[3]: http://hg.mozilla.org/mozilla-central/file/a235bfcc8c41/media/libav/libavcodec/rdft.c#l117

Comment 4

[Andrew McCreight [:mccr8]]

I don't see ff_cos_32768 and the like in the output of njn's script from bug 1254777 any more. I'm not sure if that's an issue with the script or what. We still build that code, so I have no idea why it is not showing up.

Comment 5

[Andrew McCreight [:mccr8]]

Oh, right, it isn't in libxul. I found it in another one of the .so files.

Comment 6

[Nicholas Nethercote [inactive]]

The all.syms file produced by the script is the combination of all the individual .syms files, so look at that file for the complete picture.

Comment 7

[Andrew McCreight [:mccr8]]

I looked at this a little bit, but I think I have ideas related to reducing content process memory usage that are more important than this, so I'm not going to look at it any more. These tables look like they are only initialized for some Web Audio stuff.

Comment 8

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

The best solution here is probably to move libav into a single GMP sandbox process.

Comment 9

[Andrew McCreight [:mccr8]]

I don't think this is really 655kb of memory. Per comment 1, these only use address space until the tables are generated, and presumably most processes aren't playing whatever media format this is. (Address space is not going to be at a premium in the Fission world.)

Comment 10

[Andrew McCreight [:mccr8]]

libav is being removed in bug 1476231, so I guess we can dupe this to that?

Comment 11

[Karl Tomlinson (:karlt)]

These are used for certain Web Audio node types.  The tables are generated
on-demand and only when required for those types.

Bug 1476231 doesn't really completely fix this bug because it replaces the
Libav code with similar FFmpeg code.

However, the FFmpeg code is sensible enough to generate only cos tables,
because sin tables contain the same data in different places, and so the
used overhead is reduced considerably.

The changes in Bug 1476231 also do not include the unused _fixed tables.

I would guess that the proportion of processes using Web Audio is small
enough that the extra memory used by these processes is worth the saving
in binary size.

Also note that Web Audio only uses FFTs of size up to 32768.  FFmpeg has
tables for 65536 and 131072.
Even if Gecko ended up generating all tables that it might ever use, it
would use about 128kB.
If generating at build time, then 512kB would be generated, and a
maximum of one quarter used, unless the code were patched.