fuzzing instrumented source code is 3x faster than fuzzing a binary with qemu.
if you compile normally it will be -O0 by default, if you compile for AFL++ then -O3 is used by default. Compile both with -O3 and
if you fuzz with qemu with -c0 then do the same with the source compile one but compile with AFL_LLVM_CMPLOG=1 env set.

Thank you. Sorry for the late reply. Easter-Family-OFF. I'll give it a try with the details you provided. Very helpful indeed.

@vanhauser-thc I continued the investigation and identified some interesting and a bit disturbing results.
All tests were operated on an x86_64 target machine

In a first run, I added the CMPLOG (with the double compilation as indicated) to my test-run and executed the before described vuln_program:

QEMU has the best average and best stddev, but CMPLOG offers the best median.
Well, that puzzled me even more, so I looked out for some more established test-case and found fuzzgoat

Operated six runs, each 10 minutes, for each category (pure, CMPLOG, QEMU) and got the following results:

Now, the CMPLOG has the best cycles and corpus count, but QEMU offers the best crashes found.

• The difference between pure and CMPLOG is not significant but visible and explainable if I refer to Fuzzing in depth
• The amount of run QEMU cycles is lower which might be understandable with the missing native instrumentation.
• The lower amount of corpuses with QEMU might be explainable as the finding might not directly match source instrumentation corpuses.
• What somehow shocks me is the saved crashes of QEMU which is the highest amongst all of the categories.

Perhaps I have to let it run longer. Or QEMU produces the best results independent whether source code is available or not.
Perhaps my understanding of saved crashes is wrong. In my simple understanding more of saved crashes shall be seen as "better" in terms of evaluating the item-under-test.

Would be great if you could share your thoughts.

well how you measure is not good :-)

cycles done: nonsense to measure on.

corpus count: does not tell you much.
For this case you can do it a bit simpler - fuzz with any afl++ setup you want, qemu or native, but the coverage analysis (not corpus cound, that says nothing), you do with afl-showmap -C -i out/default/queue -o /dev/null -- ./target @@

number of crashes is not a good indicator either. better would be to use casr-afl -i out -o crashes (install rust/cargo, then cargo install casr).

Finally let it run until there is no more coverage found for 5 minutes by either instance and then stop them all.