[FFmpeg-devel] a new benchmarking option for ffmpeg - patch 1 of 2

["René J.V. Bertin"]

On Mar 06, 2013, at 19:40, Nicolas George wrote:

>> IMHO size_t is perfect for counters that cannot go negative.
> 
> For counters that can not go negative, you need an unsigned type; size_t is
> unsigned all right, but it is far from being the only one.
> 
> The problem with size_t is that it has a different size depending on the
> architecture: your program will seem to work great on your x86_64 and may
> fail on a x86_32.
> 
> size_t is for the size of objects in memory, because it is directly linked
> to the limitations of the architectures.
> 
> For integers that need to handle large values, ffmpeg use (u)int64_t.

Agreed, the thing is that I'm not sure uint32_t is likely to flow over ... unless on a VERY fast machine on which the wait will be tolerable (I can't really imagine running benchmarks that take forever) ... and that machine will probably have size_t defined as at least uint64_t .
Using 64 bit integers on 32 bit hardware (or in 32 bit mode) gives a performance hit except (AFAIK) on the PowerPC G5 .

> thanksForFixingItButIAssureYouThatCamelCaseIsInherentlyUglyJustConsider
> HowPainfulItWasToReadThisSentenceSpacesWereInventedForAGoodReason.

Using_variable_or_function_names_with_such_long_names_is_just_as_bad_an_idea_and_certainly_not_prettier_written_like_this :P

> I see the point. If these functions are useful, they may have their place in
> libavutil, so that they can be used elsewhere. This reminds me that
> libavutil already has hi-res timers, for the START/STOP_TIMER macros: see
> libavutil/timer.h. Having this kind of redundant declarations is definitely
> a bad idea.

I'll have a(nother) look at those then.

R.