Use existing VALUES field instead of values()

[TheDGOfficial]

Small allocation optimization, VALUES field already existed in the enum so I figured we could use it. Saw it on a Spark report originally.

Likely very minor gains to be noticeable. I haven't extensively tested it, but from a quick test the game runs fine with the patch.

I have not checked all the usages of the method to verify the return value is not modified, but modifying an enum's values would be terrible anyways, so returning the same VALUES constant instead of allocating a new array everytime from values() should be safe and the VALUES field already exists, suggesting that this code was just forgotten to be updated to utilize it over values().

I have not checked if any other place could be turned from values() to VALUES, but this was the only code path I saw in my Spark reports.

Testing

1. /sparkc profiler start --thread * --alloc
2. Wait for a while, play normally
3. /sparkc profiler stop
4. Open result from link, look in "Chunk Render Task Executor" thread

[IThundxr]

VALUES is a private field, you'll need to use a accesswidener/accesstransformer or accessor to even access it.

[TheDGOfficial]

VALUES is a private field, you'll need to use a accesswidener/accesstransformer or accessor to even access it.

It compiled and launched fine for me. Looking at the code, it's defined as a public static final field:

sodium/common/src/main/java/net/caffeinemc/mods/sodium/client/model/quad/properties/ModelQuadFacing.java

Line 22 in 9da93ab

public static final ModelQuadFacing[] VALUES = ModelQuadFacing.values();

[IThundxr]

ah yeah, didn't see that properly, $VALUES is the field that's not public and is generated by the compiler