New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache method handle in Format #62
base: master
Are you sure you want to change the base?
Conversation
MrMks
commented
Feb 2, 2023
- StringBuilder#isEmpty is not available on Java 8, so I change it to length comparison.
- use MethodHandle and cache them for better performance
* StringBuilder#isEmpty is not available on Java 8, so I change it to length comparison.
* StringBuilder#isEmpty is not available on Java 8, so I change it to length comparison.
Is it correct for the method name of 'b' for pre 1.18? It returns an int, but we actually need a string here.
I always appreciate any contribution so thank you. I do have to ask what are we discussing for the performance? Are there performance issues that warrant the changes? It does add complexity to an already complex workflow. And I would have to refactor all of these changes to the 4.0 dev branch. |
@@ -121,7 +212,7 @@ private static String convertPlaceholders(String s, JsonFormat format, Mineverse | |||
hover.append(Format.FormatStringAll(st) + "\n"); | |||
} | |||
final String hoverText; | |||
if(!hover.isEmpty()) { | |||
if(hover.length() != 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know isEmpty() isn't available in older Java versions, but I don't think I should be forced to develop against older versions. Java 17 is the new LTS. The 4.0 dev branch uses Java 17 features as well, so it's a lot more than just this one line.
You are right, Java 17 is a good choice, but I'm using a bukkit on forge server(named CatServer) and older forge don't support newer Java, so it is hard for me to migrate to Java 17. About the performance issue, it seems like that getMethod runs a caller check behind, and the check cost a lot of time. I found this in one spark profiler. Call setAccessible(true) on Method instances and then cache them can bring us a better performance, in this case, we can reduce the times of caller check. Going further, if we use MethodHandle in a proper way, we may get the best performance. Java's c1 and c2 compiler will inline frequently used and immutable handles, as the result, it runs like we directly call those methods. p.s. my English is bad, there may be many wrongs in my sentences. If it is really hard to understand what I mean, I'd like to use a translator then. |