Describe the bug

After having run the full big5 benchmark to create the index, I ran the following command to isolate a simple query and run it as fast as possible:

opensearch-benchmark execute-test \
  --target-hosts localhost:9200 \
  --workload big5 --workload-params 'number_of_replicas:0,target_throughput:0,search_clients:8,test_iterations:100000' \
  --pipeline benchmark-only --include-tasks term \
  --kill-running-processes

This is a super fast query, so I was specifically looking for overhead in things not related to doing heavyweight search work. It turns out FeatureFlags.isEnabled is taking almost 5% of CPU cycles. It is unsurprising that a feature flag check might pop up in hot path code, and there's no reason that looking up a setting value should be so expensive. It turns out the System.getProperty check is kind of slow (because of a security manager check it seems).

Related component

Search

To Reproduce

See above

Expected behavior

Features flags defined in system properties are not dynamic. All feature flags are statically known. We should pre-populate these booleans into an immutable map during static initialization to avoid the System.getProperty call at runtime.

Additional Details