On Sat, 30 Aug 2014 19:58:11 +0200 Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> On 30.08.2014, at 19:46, Reimar Döffinger <reimar.doeffin...@gmx.de> wrote: > > On 30.08.2014, at 19:01, wm4 <nfx...@googlemail.com> wrote: > >> > >> but still I wonder why you'd optimize > >> for binary size, in exchange for higher RAM usage. What is your > >> motivation for doing this? > > > > The only higher RAM usage would be when you actually use H.264, and it > > would be from the two additional lines of code. > > When you are not using H.264 the RAM usage (with some caveats on what the > > linker does) will be several 100 bytes lower. > > Small amendment: I missed that Linux seems to use copy-on-write for the data > section. > This means that the first 512 bytes of the table could in theory end up being > shared. You'd have to be lucky enough that they just end up on a different > page than the rest of the array. At the same time, the extra RAM usage when > H.264 is not used would be once per system, not per process. > I still wouldn't count it as using "more RAM", especially considering not all > OSes handle this as nicely as Linux, but it makes it a bit more borderline. OK... never mind then. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel