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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".