-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Refactor getJarMemberSet(...) & getResourceFromLocation(...) #68
Conversation
We've updated the style back to the usual project style (not to get into a style fight at all, but consistency is probably a good thing. I hope you don't mind!), and made one very minor update to speed up some bit calculation (removed the while loop, made it a mathy thing). |
Hi Roel, regarding the while loop: I "borrowed" that from HashMap in Java 6. Quite clever. (But I also like your solution too) What is less good, is that "final" has been consistently removed. But much more important: "final" is a statement that this variable is Anyway, I'm proud to be able to contribute to lombok. All the best, On 26/05/2015 22:45, Roel Spilker wrote:
|
Hi again Roel, I just wanted to touch base with you about something I've been mulling I didn't make any change to the memory-footprint of ShadowClassLoader. I've tried about 5 different implementations to emulate the jar
The result is, I've come to the conclusion "how much memory does it use?" I know, who cares! Anyway, my best performer, a LinkedHashMap<String, LinkedHashSet> The fastest solution is the one you've just checked in. Anyway, the ravings of a madman, but I just wanted to share that with All the best, On 27/05/2015 00:07, David Law wrote:
|
Lombok certainly isn't even remotely close to the 'cleanest' code that I think I'm capable of writing; there's a lot of leeway given to the fact that lombok is a bit hacky in nature. 'final' local variables produce the exact same bytecode. It is simply impossible for it to make any performance difference. final fields on the other hand, that's a different story. Where there is a tossup between slightly more 'explicit' code such as 'final', and less code, we tend to lean towards the 'less code' side of the spectrum. This applies in particular to final variables and parameters. We do still like the notion of declaring variables as unchangable, which is why 'lombok.val' is a thing, of course! We thought WE took performance tweaking seriously, but clearly we have a lot to learn here. You've taken it to awesome extremes. Thanks for the push! -Roel and Reinier |
Hi Roel and Reinier, yeah, for old mainframers performance has always been a virtue. You young guys just buy a faster box. :-) Anyway, I ran your tweaked power-of-2 calculation through my benchmark As you can see, the Java guys managed to improve a bit with the Java 8 Start time.: 23:05:13.106 (PowerRoel2 only works in my benchmark harness, as the tests are wrapped I wonder... @benchmark All the best, On 27/05/2015 01:55, Roel Spilker wrote:
|
Bugfix for missing Jar contents mitigation & 33x performance improvement.
See: https://groups.google.com/forum/#!topic/project-lombok/YNcYxVPM8as