Eli Delventhal
|
 |
«
Reply #30 - Posted
2011-01-25 20:31:13 » |
|
Actually, this just becomes slow casting under the hood. Templates in Java are kind of crap. If you're worried about performance, better to make a subclass of ArrayList that accepts only a certain type of class. Then you can deal with the type casting yourself and make it maximally efficient.
But FYI, here is something like what I was referring to: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
| public class MonkeyArrayList extends ArrayList { public Monkey get(int i) { return (Monkey) super.get(i); }
public void add(Monkey m) { super.add(m); }
} |
You honestly think this is faster? I don't get it. Generics does exactly the same, except that is doesn't do the cast in the ArrayList, but at the callsite. What you do is moving the cast from the usual callsite into your own (newly created) callsite. For HotSpot it's exactly the same code, while your subclass even adds another level of indirection. I'm stumped. Well you'll have half as many casts, because the setters don't also need a cast. Or maybe I'm wrong and generics don't do a cast at that point, but I thought they did. But really in the end no I don't think this is worth worrying about if your reason for doing it is speed. I would argue that in some situations it has more clarity, and you avoid some of the other issues mentioned in that article (like you can have MonkeyArrayList.staticVar separate from ApeArrayList.staticVar, for example).
|
|
|
|
princec
|
 |
«
Reply #31 - Posted
2011-01-25 21:32:28 » |
|
Aye Eli is a little misled on the application of generics. Generics don't make things faster or slower; but they do provide an extra level of compiler checkery which can make some code neater. Some code not so neat. Roll on project Coin which will sort it out. Generics are like salt: use sparingly but effectively. <edit> Also, casts in the JVM are much more cunning than you think. Cas 
|
|
|
|
Eli Delventhal
|
 |
«
Reply #32 - Posted
2011-01-25 21:35:18 » |
|
Aye Eli is a little misled on the application of generics. Generics don't make things faster or slower; but they do provide an extra level of compiler checkery which can make some code neater. Some code not so neat. Roll on project Coin which will sort it out. Generics are like salt: use sparingly but effectively. Cas  I've got to stop arguing points that I don't even really follow myself. 
|
|
|
|
Games published by our own members! Check 'em out!
|
|
princec
|
 |
«
Reply #33 - Posted
2011-01-25 21:38:44 » |
|
I used to do that  Now I just moan about Java being shit because I can't use it on the BASTARD IPHONE. Grrr. etc. Cas 
|
|
|
|
Captain Awesome
Junior Devvie   Medals: 2
Hi
|
 |
«
Reply #34 - Posted
2011-01-25 21:46:06 » |
|
I used to do that  Now I just moan about Java being shit because I can't use it on the BASTARD IPHONE. Grrr. etc. Cas  Moan on steve jobs instead for not supporting java lol.
|
|
|
|
princec
|
 |
«
Reply #35 - Posted
2011-01-25 21:48:42 » |
|
Jobsy doesn't actually mind Java at all. He's pretty good pals with Larry too. The problem was the legacy dealings Apple had with Sun. I have a feeling things might look a little rosier in the not too distant future. Cas 
|
|
|
|
SimonH
|
 |
«
Reply #36 - Posted
2011-01-25 21:53:48 » |
|
Just to satisfy my own curiosity I just did a quick test (1M add, get, remove) for generic and non-generic Vectors and found no appreciable time difference. Phew! I was hoping there wouldn't be!
|
People make games and games make people
|
|
|
JL235
|
 |
«
Reply #37 - Posted
2011-01-26 00:47:22 » |
|
Just dont bother! Stick to whats working for you and get something done before trying to optimize at this level. You wont get anywhere if you start this now. Trust me: "premature optimization is the root of all evil"
Okay, I will agree with this. Just stick with the Vector or whatever that you've got already. But FYI, here is something like what I was referring to: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
| public class MonkeyArrayList extends ArrayList { public Monkey get(int i) { return (Monkey) super.get(i); }
public void add(Monkey m) { super.add(m); }
} |
I'm surprised others failed to pick up on this. 'public void add(Object value)' still exists, so your method fails to be a full replacement to Generics. Your method is only ever called if you know a Monkey is passed in at compile time as otherwise it'll bypass it and call the old add. For example... 1 2 3 4
| MonkeyArrayList monkeys = new MonkeyArrayList(); monkeys.add( "a string" ); monkeys.add( 42 ); monkeys.add( new Monkey() ); |
The above is perfectly valid and successfully executes. To be fair you will get an exception when calling 'get' due to the cast. But consider this: if a non-Monkey is in the list then the error must have occurred at the point where the non-Monkey is added to the list (it shouldn't have been added). Because the type error only occures when calling 'get' (on performing the cast) then you have moved the error away from where it has occured. The error is now more misleading as you'd expect everything inside of 'monkeys' to already be a Monkey. Secondly you will also get an error when using an iterator or when using a foreach loop (I believe foreach loops are just iterators + syntax sugar). This is because the iterator calls 'get', but this is implementation specific! I could build a 'SpecialList' which returns an iterator which does not call 'get'. If the 'MonkeyArrayList' extends my 'SpecialList' then there should not be a runtime error when using iterators or foreach loops. Generics does not suffer from these issues. Finally yours offers no compile time validation. Generics does.
|
|
|
|
Eli Delventhal
|
 |
«
Reply #38 - Posted
2011-01-26 01:33:05 » |
|
Very good point, I wrote this quickly without thinking. To take a real-world situation, have a look at BodyList from Phys2D. It isn't an ArrayList, it has an ArrayList. I honestly momentarily debated that with myself before typing the example, obviously I made the wrong choice. You definitely wouldn't want to subclass ArrayList, that would make no sense. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151
| package net.phys2d.raw;
import java.util.ArrayList;
public class BodyList implements java.io.Serializable { private ArrayList elements = new ArrayList(); public BodyList() { } BodyList(BodyList list) { elements.addAll(list.elements); } public void add(Body body) { elements.add(body); } public int size() { return elements.size(); } public void remove(Body body) { elements.remove(body); } public Body get(int i) { return (Body) elements.get(i); } public void clear() { elements.clear(); } public boolean contains(Body body) { return elements.contains(body); } public BodyList getContentsExcluding(BodyList others) { BodyList list = new BodyList(this); list.elements.removeAll(others.elements); return list; } public String toString() { String str = "[BodyList "; for (int i=0;i<elements.size();i++) { str += get(i)+","; } str += "]"; return str; } }
|
|
|
|
|
ReBirth
|
 |
«
Reply #39 - Posted
2011-01-26 03:18:53 » |
|
Just dont bother! Stick to whats working for you and get something done before trying to optimize at this level. You wont get anywhere if you start this now. Trust me: "premature optimization is the root of all evil"
Thanks for the advice. Honestly I didn't bother this. My current small project is using ArrayList<Ball> (Ball is my own defined class) and it works well. I call get() every update() time so every Ball can draw themself and no lag. I just want to know and take a glance about optimization for future need 
|
|
|
|
Games published by our own members! Check 'em out!
|
|
cylab
|
 |
«
Reply #40 - Posted
2011-01-26 12:05:27 » |
|
I just want to know and take a glance about optimization for future need  Fair enough, but you should take a different approach: - benchmark your code - maybe it's just fast enough - profile your code to find bottlenecks (Use one of Netbeans, Yourkit, Visual VM, JProfiler etc.) Use the result of the Profiler to - replace components that are slow for your use case with fast ones - usually every component has strengths and weaknesses - reduce "exponential" complexities (like nested loops) - find another algorithm to do things that are slow (google is your friend:)) Usually performance problems exist on a completely different level than such micro-optimizations
|
Mathias - I Know What [you] Did Last Summer!
|
|
|
JL235
|
 |
«
Reply #41 - Posted
2011-01-26 14:50:26 » |
|
Very good point, I wrote this quickly without thinking. To take a real-world situation, have a look at BodyList from Phys2D ...
Ah, through composure instead. Yeah, that works. I actually used this method myself once in a library made. I also went further and wrapped an array instead of an ArrayList and then just resize it myself. There is a speed improvement, but the only real improvement you see if you also do this for primitive types. However I added this to my own code a long time after writing it (not in the first case), I did need my library to run faster (you shouldn't optimize unless it's needed) and it's only seen internally. I'd maintain you should only ever optimize under those circumstances. Considering that the original poster needed help on just how to use arrays; this kind of stuff is too advanced (and it's to early on in his code) to be suggesting.
|
|
|
|
Eli Delventhal
|
 |
«
Reply #42 - Posted
2011-01-26 18:49:12 » |
|
However I added this to my own code a long time after writing it (not in the first case), I did need my library to run faster (you shouldn't optimize unless it's needed) and it's only seen internally. I'd maintain you should only ever optimize under those circumstances.
I will agree with you. On JGO, I often get a little bit too academic about things. As I said above, I have never personally done this in any "actual" projects, because they are never my bottleneck.
|
|
|
|
Riven
|
 |
«
Reply #43 - Posted
2011-01-26 19:14:03 » |
|
I will agree with you. On JGO, I often get a little bit too academic about things.
I usually associate academic with fully thought through Ask Kev his opinion of generics and you'll get much more fire and brimstone than from me. Personally I'm going to stop arguing now, since it's already been done many times before.
This is just condescending and ill informed.
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings!
|
|
|
Eli Delventhal
|
 |
«
Reply #44 - Posted
2011-01-27 18:32:01 » |
|
I will agree with you. On JGO, I often get a little bit too academic about things.
I usually associate academic with fully thought through Ask Kev his opinion of generics and you'll get much more fire and brimstone than from me. Personally I'm going to stop arguing now, since it's already been done many times before.
This is just condescending and ill informed. Hm... I was thinking academic more referring to talking over ideas and coming to a conclusion, but yes you're right in many cases I don't think an overly long time about what I'm saying. As for the condescension, it wasn't at all intended. And I don't think that was ill informed either. I just searched the forum for "generics" in posts by kevglass. http://www.java-gaming.org/topics/type-compatibility-linkedlist/8132/msg/71311/view.html#msg71311one of the benefits of not using generics, ick! http://www.java-gaming.org/topics/please-vote-today/6441/msg/57663/view.html#msg57663I don't like generics http://www.java-gaming.org/topics/generics-good-or-bad/6164/msg/56424/view.html#msg56424They're easy to misuse http://www.java-gaming.org/topics/sun-s-crappy-generic-implementation/7180/msg/63294/view.html#msg63294Just don't use generics. They're a move toward bad programming anyway Now, I'm posting all this just to emphasize the impression I got from Kev, and not that I was trying to throw out wild opinions about what someone else thinks (which admittedly I am still doing to some extent). I will also be the first to point out that in many of the posts I quoted Kev's main point is not that generics themselves are bad, but that they allow programmers to do dumb things. So he doesn't like generics because of different reasons than I mentioned. All that said, though, I am totally aware that I too often will evangelize a point I remember reading on this very forum, but I turn out to be mistaken. I get carried away with the interest of having a discussion. I will continue to try not to discuss something as an informed individual unless I do in fact know something about the subject from my own experiences. I will also point out that my skill as a software engineer has never lied in a deep knowledge of the compiler or the OS or anything like that as your knowledge is based in, Riven, but it is in making programs come together quickly and cleanly in an intelligent fashion. I usually only worry about the underlying mechanics of what I'm using if I need to know them. So, like I already said, I should probably stop giving advice about underlying mechanics and stick to giving advice about making games.
|
|
|
|
JL235
|
 |
«
Reply #45 - Posted
2011-01-27 19:23:44 » |
|
I usually only worry about the underlying mechanics of what I'm using if I need to know them. So, like I already said, I should probably stop giving advice about underlying mechanics and stick to giving advice about making games.
I (obiously) disagreed with bits, but I didn't think there was nothing wrong with your suggestion. You certainly shouldn't feel like you shouldn't make suggestion in an area.
|
|
|
|
Eli Delventhal
|
 |
«
Reply #46 - Posted
2011-01-27 20:50:08 » |
|
I usually only worry about the underlying mechanics of what I'm using if I need to know them. So, like I already said, I should probably stop giving advice about underlying mechanics and stick to giving advice about making games.
I (obiously) disagreed with bits, but I didn't think there was nothing wrong with your suggestion. You certainly shouldn't feel like you shouldn't make suggestion in an area. Cool. I've just gotten burned one too many times for suggesting/saying something that wasn't completely correct.
|
|
|
|
|