review: perf: override AbstractMap#get in ElementNameMap

[SirYwell]

This was discovered after rebasing for #4848.

#4832 caused a severe regression due to the way get in AbstractMap works. Before, AbstractMap#entrySet() just delegated to the underlying map, but with the patch, it first has to build the map. For get, this isn't needed at all, therefore we should override the method.

This brings down this test

spoon/src/test/java/spoon/test/architecture/SpoonArchitectureEnforcerTest.java

Line 157 in 0fcb288

public void testSrcMainJava() {

from ~1m 17s to ~52s. There might be more methods that should be overridden now, I'll investigate that. One that takes a lot of time is values() which is called heavily at the moment, but we can avoid many calls with #4848, so both PRs combined seem to achieve even better performance than before the regression.

[I-Al-Istannen]

I crunched some numbers. The initial regression from @slarse's PR was approximately a factor of 2 (not placing blame here by any means, I didn't see it either and the change was good).

I ran my javadoc indexer for various configurations and got:

Before slarse order fix

266s (user) and 36 wall clock time

After slarse order fix

683s (user) and 1:23 wall clock time

After this PR

440s (user) and 55s wall clock time

After this PR and hannes/perf/PackageFactory

249s (user) and 35s wall clock time

Both changes from @SirYwell address unfortunate consequences of the inherited AbstractMap methods I didn't foresee.
@SirYwell and I really need to come up with some continuous benchmark integration, it seems. I didn't expect the impact of the PR to be that high and should have probably measured it.

[slarse]

Good find, lgtm!

The initial regression from @slarse's PR was approximately a factor of 2 (not placing blame here by any means, I didn't see it either and the change was good)

@I-Al-Istannen I blame whomever came up with inheritance, it's just too easy to shoot yourself in the foot 🤷‍♂️