Posted: 11/29/2010 1:13:07 PM EDT
|
http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/src/main/org/codehaus/groovy/runtime/ArrayUtil.java
|
|
Quoted:
Acceptable if scalability is not needed, esp if that class stays internal to library. And if you assume that you will never have more than 250 objects. Or replace that entire 1,275 line 701 KB abomination with this:
|
|
Quoted:
Quoted:
Acceptable if scalability is not needed, esp if that class stays internal to library. And if you assume that you will never have more than 250 objects. Or replace that entire 1,275 line 701 KB abomination with this: public static Object[] createArray(Object ... objects) { return new Object[]{objects};}There's something else going on there. I'm not sure exactly what, and I don't know that it's accurate, but their comments claim there are performance advantages to doing it the way they did. |
|
Quoted:
Quoted:
Quoted:
Acceptable if scalability is not needed, esp if that class stays internal to library. And if you assume that you will never have more than 250 objects. Or replace that entire 1,275 line 701 KB abomination with this: public static Object[] createArray(Object ... objects) { return new Object[]{objects};}There's something else going on there. I'm not sure exactly what, and I don't know that it's accurate, but their comments claim there are performance advantages to doing it the way they did. I was wondering when you'd show up 
|
|
Quoted: Quoted: Quoted: Acceptable if scalability is not needed, esp if that class stays internal to library. And if you assume that you will never have more than 250 objects. Or replace that entire 1,275 line 701 KB abomination with this: public static Object[] createArray(Object ... objects) { return new Object[]{objects};}There's something else going on there. I'm not sure exactly what, and I don't know that it's accurate, but their comments claim there are performance advantages to doing it the way they did. Probably the overhead of varargs may be higher than explicit number of args. Edit: the compiler deals with it a compile time and not runtime. |
|
Quoted:
Quoted:
Quoted:
Quoted:
Acceptable if scalability is not needed, esp if that class stays internal to library. And if you assume that you will never have more than 250 objects. Or replace that entire 1,275 line 701 KB abomination with this: public static Object[] createArray(Object ... objects) { return new Object[]{objects};}There's something else going on there. I'm not sure exactly what, and I don't know that it's accurate, but their comments claim there are performance advantages to doing it the way they did. I was wondering when you'd show up 
I'm guessing this is one of those things that, like assembly, looks absolutely horrific (and I agree with you that it does), but compiles very well. I'm not a java fan at all, just for the record. |
|
Quoted:
Quoted:
Quoted:
Quoted:
Quoted:
Acceptable if scalability is not needed, esp if that class stays internal to library. And if you assume that you will never have more than 250 objects. Or replace that entire 1,275 line 701 KB abomination with this: public static Object[] createArray(Object ... objects) { return new Object[]{objects};}There's something else going on there. I'm not sure exactly what, and I don't know that it's accurate, but their comments claim there are performance advantages to doing it the way they did. I was wondering when you'd show up
I'm guessing this is one of those things that, like assembly, looks absolutely horrific (and I agree with you that it does), but compiles very well. I'm not a java fan at all, just for the record. Oh I know you're not, that's why I expected you here sooner! 
|
|
Quoted:
Quoted:
Quoted:
Quoted:
Quoted:
Quoted:
Acceptable if scalability is not needed, esp if that class stays internal to library. And if you assume that you will never have more than 250 objects. Or replace that entire 1,275 line 701 KB abomination with this: public static Object[] createArray(Object ... objects) { return new Object[]{objects};}There's something else going on there. I'm not sure exactly what, and I don't know that it's accurate, but their comments claim there are performance advantages to doing it the way they did. I was wondering when you'd show up
I'm guessing this is one of those things that, like assembly, looks absolutely horrific (and I agree with you that it does), but compiles very well. I'm not a java fan at all, just for the record. Oh I know you're not, that's why I expected you here sooner! My hatred for it is not as intense as it once was –– I'm in the middle of a 400 level OO class using Java right now, and have learned a lot more about it. It's a good class. I still don't like it though... |