Dave Marion

I agree with your observations here. I'll admit that I don't fully understand the layers of configuration objects here. I do think there is an opportunity to consolidate some of...

It's being used in `AccumuloConfiguration.get(String)` and `AccumuloConfiguration.iterator`

> It doesn't save from having to iterate over the properties in AccumuloConfiguration.get(String) case, either (because we're still iterating in the new method body) We are iterating over the varargs...

> I don't think it will substantially affect performance, given that looking up a small number of properties this way would be rare anyway. > However, I don't think it...

> I believe you've optimized for a case that shouldn't be called instead of fixing the calling code. That's a fair observation. I didn't question the existing code. It may...

@ctubbsii - are you working on anything related to this? If not, I can start on the things you mentioned above.

@ctubbsii - See https://github.com/apache/accumulo/pull/2864. I reverted the two commits and added a 3rd. In the 3rd commit I reduced calls to AccumuloConfiguration.get(String) and optimized that method.

I just re-ran this using `cingest ingest`, `cingest verify` and `cingest scan` ``` grep accumulo *.out | grep "hot method too big" | awk '{ print $(NF-6) }' | sort...

I just: 1. created a small cluster from the `main` branch 2. added the following to `JAVA_OPTS` in `accumulo-env.sh` ``` -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining ``` 3. ran `cingest` commands 4. `grep...

Also, some, or all, of these methods might not meet the criteria for inlining unless they are refactored. If you are not familiar with it, [here](https://www.baeldung.com/jvm-method-inlining) is a good explanation.