[FFmpeg-devel] [PATCH V5 1/2] configure: sort decoder/encoder/filter/... names in alphabet order

Alexander Strasser eclipse7 at gmx.net
Sat May 4 02:09:19 EEST 2019


Hi Avih!

On 2019-05-02 08:55 +0000, avih wrote:
> > It seems awk is unconditionally required already. However I wanted to
> > say that it's a very nice dep to have
>
> While it's possibly nicer than other deps to have, it's still better to use
> it IMHO only when it adds some value, like simpler code, better performance,
> compliance with some things, etc.

Agreed; of course we shouldn't just use awk because we can.

Though I think not implementing things in shell is often
lower risk, as we have no isolation in POSIX shell, we all
share the same variables etc. and the configure script is
quite big. Then shell is not suited for many tasks because
of the way it works, like you explained really good before.
So even if we find an acceptable solution, it will not be
understood that easily by most people, because most people
are not that deep into shell programming.

Also in my experience the shells differ, when using more
advanced concepts and in things that aren't used widely.

Some of what I said applies to the alternatives too,
except that they will always be better isolated.

Sorry, that turned out longer than I wanted it to be :(


> With this patchset, for part 1 I'm not sure I see the added value with awk,
> as it looks about the same complexity of the code compared to the shell
> version.

Did you look at the version I attached in this thread? Or the one I
posted in the new patch set?

I changed it to use an algorithm more similar to the latest shell
version discussed here. The version I attached in this mail thread,
was an experiment to see if it could be easier understood that way.


> Performance-wise it's negligible as print_in_columns() is only called
> about 5 times (but with thousands of values to process), so as long as the
> loop is efficient, the additional awk process per call is barely measurable.


> For part 2 the awk version is simpler code, but `log_file()` is called nearly
> 300 times, mostly with files with less than 5 lines to print. At this case it
> does add a performance penalty, especially on systems where a new process is
> expensive.

Yes, exactly. Very well worded!

Though I am still surprised about the Windows results. I did not
investigate more, but I found it quite strange, that it showed
a 8% performance hit the first time, and in subsequent runs there
were no performance differences measurable for the runtime of the
complete configure script.

As mentioned in the other patch set, I am fine going with the shell
version for part 2 (log_file).

A third option would be to just use cat and forget about the line
numbers. I am not sure the numbers really add much value, for those
dumps of mostly very small source files with little ambiguity.


  Alexander


More information about the ffmpeg-devel mailing list