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

Reply via email to