[FFmpeg-soc] [soc]: r5419 - als/alsdec.c

[Michael Niedermayer]

On Thu, Oct 22, 2009 at 01:32:15PM +0200, Thilo Borgmann wrote:
> Michael Niedermayer schrieb:
> > On Thu, Oct 22, 2009 at 11:29:55AM +0200, Thilo Borgmann wrote:
> >> Thilo Borgmann schrieb:
> >>> Michael Niedermayer schrieb:
> >>>> On Wed, Oct 21, 2009 at 12:33:21PM +0200, Thilo Borgmann wrote:
> >>>>> Michael Niedermayer schrieb:
> >>>>>> On Tue, Oct 20, 2009 at 03:00:40PM +0200, thilo.borgmann wrote:
> >>>>>>> Author: thilo.borgmann
> >>>>>>> Date: Tue Oct 20 15:00:40 2009
> >>>>>>> New Revision: 5419
> >>>>>>>
> >>>>>>> Log:
> >>>>>>> Splits reading of block data and decoding of block data.
> >>>>>>> Introduces ALSBlockData struct.
> >>>>>> You are missing the "why" part, that should be explained in the commit
> >>>>>> message
> >>>>> Yes, sorry.
> >>>>>
> >>>>>> also this needs a benchmark as there are many additional dereferences
> >>>>>> added
> >>>>> It is a necessary evil to support MCC. If it would be faster the "old"
> >>>>> way for non-MCC files, would this reason to have both, a split read &
> >>>>> decode function pair and an all-in-one function?
> >>>> I think a benchmark is usefull to judge if we should spend time thinking
> >>>> about alternatives to the many dereferences or not
> > [...]
> >>> This is a 30% difference which makes me think to try these alternatives.
> >>>
> >>> What comes into my mind would be to use local copies, thus dereferencing
> >>> the field of *bd just twice. One at the top and one at the bottom of the
> >>> function.
> >>>
> >> I tested using local copies instead of dereferencing:
> > [...]
> >> That's a 4% gain so I think local copies don't pay off...
> >>
> >> Other alternatives?
> > 
> > i would first confirm that gcc did not do something stupid about inlining.
> > Or more precissely not inlining some random unrelated function after the
> > file got bigger ...
> 
> How to do that?

nm -S foobar.o
will show you things that are not inlined and how large they are

you can also use gcc to compile code to .s files and use grep on them

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20091022/1d9b76bb/attachment.pgp>