[XviD-devel] [RFC] memcpy thingy

[Edouard Gomez]

Christoph Lampert (chl at math.uni-bonn.de) wrote:
> Only, when  people shout "but, it's  not problem, let's  really put it
> in" (which you just did), I give in an say "okay".

hehe

Btw we  can live w/o ultra  optimized memcpy... numbers  speak much more
than all  that fud on  doom9. Here is  the cruel reality as  reported by
gprof.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    

With libc-like memcpy (i can't really profile the libc functions)
  1.72    215.97     5.08                             memcpy_x86
  1.24    237.67     3.66     1473     2.48     2.48  image_setedges
With the xmm version (very similar result with mmx)
  1.59    226.13     4.71                             memcpy_xmm
  1.18    242.43     3.50     1473     2.38     2.38  image_setedges

first two rows are irrelevent, only the self seconds matters for
comparison purpose.

This was for a typical frame size of 640x272, 1000 frames sequence...

For me this represents
 - 0.5s gain every 1000 frames in a typical dvd rip
 - for a 2h movie (180000 frames), that represents a 1min30s
 - as i rip a 2h movie in ~2h40... this gain is ...

   ... quite ridiculous :-P

So i'll  wait a bit before commiting  and as sysKin says,  we would gain
much more not trying to edge frames more than once :-) (see the function
is  called  1473  times  for  a 1000  frame  sequence)  than  optimizing
scanline tranfers.

-- 
Edouard Gomez