Over the past decade, hundreds of fuzzers have been published in top-tier security and software engineering conferences.

Fuzzers are used to automatically test programs, ideally creating high-coverage input corpora and finding bugs.

Modern ``greybox'' fuzzers evolve a corpus of inputs by applying \emph{mutations} to inputs and then executing those new inputs while collecting coverage.

New inputs that are ``interesting'' (e.g. reveal new coverage) are saved to the corpus.

Given their non-deterministic nature, the impact of each design decision on the fuzzer's performance can be difficult to predict.

Some design decisions (e.g., " Should the fuzzer perform deterministic mutations of inputs? ") are exposed to end-users as configuration flags, but others (e.g., " What kinds of random mutations to apply to inputs?") are typically baked into the fuzzer code itself.

This paper describes our over 12.5-CPU-year evaluation of the set of mutation operators employed by the popular AFL++ fuzzer, including the \textit{havoc} phase, splicing, and \redqueen, exploring the impact of adjusting some of those unexposed configurations.

In this experience paper, we propose a methodology for determining different fuzzers' behavioral diversity with respect to branch coverage and bug detection using rigorous statistical methods.

Our key finding is that, across a range of targets, disabling certain mutation operators (some of which were previously ``baked-in'' to the fuzzer) resulted in inputs that cover different lines of code and reveal different bugs.

A surprising result is disabling certain mutators leads to \textbf{more diverse} coverage and allows the fuzzer to find \textbf{more} bugs \textbf{faster}.

We call for researchers to investigate seemingly simple design decisions in fuzzers more thoroughly and encourage fuzzer developers to expose more configuration parameters pertaining to these design decisions to end users.