Re: [FFmpeg-devel] [PATCH 10/39] lavc/ffv1dec: move the bitreader to stack

[Anton Khirnov <anton@khirnov.net>]

Quoting Michael Niedermayer (2024-07-18 20:18:15)
> On Thu, Jul 18, 2024 at 05:31:16PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-07-18 16:48:06)
> > > On Thu, Jul 18, 2024 at 11:08:59AM +0200, Anton Khirnov wrote:
> > > > Quoting Michael Niedermayer (2024-07-18 00:42:05)
> [...]
> > > >
> > > > Another factor that matters in efficient cache use is e.g. not having
> > > > multiple copies of the same constant data scattered around, which you're
> > > > objecting to in my other patches.
> > > 
> > > copying the actually used small data together per slice
> > > where its accessed per pixel should improve teh speed per pixel while
> > > making the per slice code a little slower. now we have 4 slices maybe
> > > and millions of pixels. Thats why this can give an overall gain
> > 
> > This all sounds like premature optimization, AKA the root of all evil.
> > As I said above, I intended to make this code more readable, not faster.
> > Yet somehow it became faster anyway, which suggests this code is not
> > very optimized. So then arguing whether this or that specific change
> > adds or removes a few cycles per frame seems like a waste time to me.
> 
> Making the code faster is welcome
> Making the code cleaner is welcome
> 
> whats faster is objective (mostly)
> whats cleaner is not objective. So we could agree or disagree on that
> 
> Things that make the code slower, and dont provide a larger improvment
> elsewhere i do object to
> 
> About "premature optimization", i have not seen any optimizations being
> removed that made the code hard to maintain or work with so this is
> not a nice statement.
> And iam the first to suport making the code cleaner and easier to maintain
> as iam the one maintaining it.
> 
> Either way, thanks for your efforts in improving the ffv1 code, they
> are appreciated, my objections are not meant to hinder improvments
> i just want to make sure it all one by one is an improvment

As I said in my other reply, patches 07-25 moving per-slice data to a
new per-slice struct should be considered as one change, as it does not
make sense to apply only some of them and not the others. Some of them,
taken individually, may introduce transient slowdown, because
temporarily there are two per-slice contexts.

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".