6 ms·
Or if you need that much, your design is severely broken
by RobertDeNiro 7y ago
Or if you need that much, your design is severely broken
- blattimwind 7y agohttps://github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/runtime/ArrayUtil.java https://github.com/groovy/groovy-core/blob/master/src/main/o...
- cobbzilla 7y agoWow -- that is some ugly code. Why couldn't they use a single varargs method declaration? Does this code need to support older Java versions that lack varargs support?
- lokedhs 7y agoIt may be a performance hack. Varargs results in an array being allocated. I've seen this trick in the past, but they usually stopped at a handful of arguments and let the rest be handled by varargs.
- usrusr 7y agoGroovy is chock-full of absurd little microoptimizations that will forever fail to make even the tiniest dent in the general overhead relative to java. For several years there was even an "assume equality of hashes match" shortcut hidden in certain set operation code paths.
- zmmmmm 7y agoWhen compiled statically groovy has almost zero overhead relative to Java. I appreciate how much effort they have made to keep the overhead low and reduce the bloat as much as they can.
- Someone 7y agoRead the code comments. ”The purpose is the reduction of the size of the bytecode.”
- kccqzy 7y agoYou can quite clearly see, though, how many arguments GitHub's code highlighter thinks a Java method should have.
- Rebelgecko 7y agoAn auspicious and possibly immature number
- mattcoles 7y ago70?
- vorg 7y agoThe Java methods with up to 70 arguments are highlighted. This code defines methods with up to 250 arguments. I wonder why the Apache Groovy people didn't choose a number like 256, which is more compatible with other magic numbers in the JVM.