Hi,
I have one array list having more than 100 objects in it.
I have two way to ietrator.
1.
for(int i=0; i<list.size(); i++)
{
Object o = list.get(i);
}
2.
Iterator i = list.getIterator()
while(i.hasNext())
{
Object o ...
}
which is better in performance ?>
> which is better in performance ?
This tells me you haven't thought this through.
A 100 Object ArrayList takes a couple microseconds to loop through, maybe a millisecond.
The average person lives about 80 years, figure 254608000000 milliseconds, counting leap-years. Fact is, you've spent more time asking this question than it will take you to run those loops.
In short, Premature Optimization is the Root of All Evil.
~Cheers
Oh, by the way.
For a RandomAccess List like ArrayList, the first method is probably faster. However, it is good design practices to work with a generic type, like "List," and just assign it to an ArrayList value. Therefore, the second is probably the prefered method.
Or, in Java 1.5...
for(Object o : list)
{
o.doSomethingAnObjectCanDo();
}
> > Therefore,
> > the second is probably the prefered method.
>
> ....because, when you access items in a LinkedList by
> index, the list has to walk across a bunch of nodes
> to get to the item. This means that your iteration
> degenerates into a O(n^2) operation.
Interesting.
Just goes to show that it's important to understand data structures and their behavior when you select one. Gotta keep in mind what you're going to do (e.g., read-only, add new items in the middle, etc.) when you decide on a runtime type.
%
> > Therefore,
> > the second is probably the prefered method.
>
> ....because, when you access items in a LinkedList by
> index, the list has to walk across a bunch of nodes
> to get to the item. This means that your iteration
> degenerates into a O(n^2) operation.
You're right in principle of course. In practice though it's possible to make an easy optimization. The LinkedList just needs to save the most recent used index and the corresponding node pointer. If in the next access the index is incremented by 1 no search from the beginning has to be made because the next node is pointer.next.
So in practice, I would guess, an indexed walk-through of a LinkedList is O(N).
> which is better in performance ?
A straight answer is that the first one is the fastest.
This isn't a very good argument to use it though. Only consider performance when you know it matters. Instead you should go for the highest abstraction level available to you and in verson 1.5 of Java it's the foreach loop (mentioned in #2).
> So in practice, I would guess, an indexed
> walk-through of a LinkedList is O(N).
No. This is what is does:
Entry e = header;
if (index < (size >> 1)) {
for (int i = 0; i <= index; i++)
e = e.next;
} else {
for (int i = size; i > index; i--)
e = e.previous;
}
It always starts from the header and walk forward or backward depending on whether one is a shorter distance.
> Well okay. It's an easy optimization but I guess Sun
> doesn't want to "bail out" people who don't know
> their data structures.
It won't always be optimal, though. If you use iterators and don't iterate the whole way through every time, it would degrade performance. It's hard for them to make assumptions about how you will access the data. So you punish people who do use it properly if you do that.
> > Well okay. It's an easy optimization but I guess Sun
> > doesn't want to "bail out" people who don't know
> > their data structures.
>
> It won't always be optimal, though. If you use
> iterators and don't iterate the whole way through
> every time, it would degrade performance. It's hard
> for them to make assumptions about how you will
> access the data. So you punish people who do use it
> properly if you do that.
I don't know. The optimization I suggested is isolated to random accesses in the linked list only. Say you access index 5. The node pointer corresponding to 5 is stored and if the next access is index 6 the node pointer you're looking for is pointer.next. There's no need to walk the list from the beginning.
As implemented in 1.4.2 the LinkedList iterator has the same O notation as the index operation for an ArrayList.
The iterator itself is walking the list and it keeps track of the last node.
public Object next() {
checkForComodification();
if (nextIndex == size)
throw new NoSuchElementException();
lastReturned = next;
next = next.next;
nextIndex++;
return lastReturned.element;
}
Presumably the O notation for the ArrayList iterator is the same as the direct operation.
> By the way the opimization principle I mentioned is
> quite common (to make predictions about the likely
> next access). It's used in memory caches for example.
Can you demostrate how that would be implemented? I'm not convinced it's feasible. LinkedList elements don't have an internal index and I if they did, the LinkedList would have to iterate over the list whenever elements were added to the beginning or middle; defeating the point of using a LinkedList. Consider the following.
for (int i = 0; i < list.length; i+=2)
{
list.add(i, something);
}
> > By the way the opimization principle I mentioned
> is
> > quite common (to make predictions about the likely
> > next access). It's used in memory caches for
> example.
>
> Can you demostrate how that would be implemented?
> I'm not convinced it's feasible.
Huh? Maybe we have different interpretations of that reply.
It is trivially simple to implement. And the LinkedList iterator already does exactly that.
> LinkedList
> t elements don't have an internal index and I if they
> did, the LinkedList would have to iterate over the
> list whenever elements were added to the beginning or
> middle; defeating the point of using a LinkedList.
I don't believe the comment was directed at all linked lists but rather a subset with known usage patterns.
Consider a memory manager where it keeps a free block list. Free blocks are always added at the end. They are never added at the beginning or middle. And obviously in this case keeping track of the last node is optimal because that is where the newly freed blocks would be added.
> Huh? Maybe we have different interpretations of that
> reply.
>
> It is trivially simple to implement. And the
> LinkedList iterator already does exactly that.
No it doesn't. She is saying that each call to get(int) would store the node at that index. Then the next call to get(int) would search from that index.
> I don't believe the comment was directed at all
> linked lists but rather a subset with known usage
> patterns.
I don't know what that means. We are talking about the Java LinkedList class that comes with the JDK.
> Consider a memory manager where it keeps a free block
> list. Free blocks are always added at the end. They
> are never added at the beginning or middle.
What does that have to do with anything?
> And
> obviously in this case keeping track of the last node
> is optimal because that is where the newly freed
> blocks would be added.
Great.
> > By the way the opimization principle I mentioned is
> > quite common (to make predictions about the likely
> > next access). It's used in memory caches for
> example.
>
> Can you demostrate how that would be implemented?
> I'm not convinced it's feasible. LinkedList
> t elements don't have an internal index and I if they
> did, the LinkedList would have to iterate over the
> list whenever elements were added to the beginning or
> middle; defeating the point of using a LinkedList.
> Consider the following.
I've already explained it in #13. You just have to keep track of the last index and the corresponding internal node pointer. If the user then wants index+1 the corresponding node will be pointer.next. Because LinkedList is doubly linked the node corresponding to index-1 is also easy to find, it's pointer.prev.
With the above simple optimization this would execute on O(N) (and not O(N^2)),
for (int i=0; i<ll.size(); i++) // ll is a LinkedList
Object o = ll.get(i);
>
> I've already explained it in #13.
Explain what this will do when I execute the following:
list.get(5);
list.add(5, "new");
// later
list.get(5);
> You just have to
> keep track of the last index and the corresponding
> internal node pointer. If the user then wants index+1
> the corresponding node will be pointer.next. Because
> LinkedList is doubly linked the node corresponding to
> index-1 is also easy to find, it's pointer.prev.
I guess you mean you would also do this on adds?
> With the above simple optimization this would execute
> on O(N) (and not O(N^2)),
Yes, obviously.
> > I've already explained it in #13.
>
> Explain what this will do when I execute the
> following:
> list.get(5);
>
Sequences through the list. Sets the tracking node.
> list.add(5, "new");
Removes the tracking node.
>
> // later
>
> list.get(5);
No tracking node so it does the same as the first time.
> > Huh? Maybe we have different interpretations of that
> > reply.
> >
> > It is trivially simple to implement. And the
> > LinkedList iterator already does exactly that.
>
> No it doesn't. She is saying that each call to
> get(int) would store the node at that index. Then
> the next call to get(int) would search from that
> index.
So my interpretation was different.
Still easy to add though.
Pseudo code would look something like this..
Get(index)
- Is index != trackingIndex+1 do regular list scan and set trackingIndex, trackingNode
- else use trackingNode to get next and return that.
Add(index, item)
- Reset trackingIndex, trackingNode
- Do normal add.
> Get(index)
> - Is index != trackingIndex+1 do regular list scan
> and set trackingIndex, trackingNode
> - else use trackingNode to get next and return that.
If you have the tracking node and the index, why not determine whether it's closer than the head and use it if it is?
> Add(index, item)
> - Reset trackingIndex, trackingNode
> - Do normal add.
That's one way to do it, you could also set the tracking node to the last added also.
> I've been mostly concerned with the get() situation.
> Add() restructures the list so maybe it's more
> complicated but I wouldn't say it's impossible.
That was my point. Just adding code to get wouldn't work.
> Anyway this optimization isn't performed so it's only
> hypothetical.
I suppose you could just handle it in the same place that it sets flags for concurrent modifications.
> > No, get() must be noted if the list has been
> > restructured between calls.
>
> That still requires writing code in other methods.
> Otherwise you introduce a bug. You can't modify
> y get(int) only. You have to add code to reset this
> when the list is modified.
So when you said that you thought it wasn't feasible you meant it wasn't feasible to just modify the get() method by itself? Then yes that isn't feasible. But other than that it is easy.
> > Get(index)
> > - Is index != trackingIndex+1 do regular list scan
> > and set trackingIndex, trackingNode
> > - else use trackingNode to get next and return
> that.
>
> If you have the tracking node and the index, why not
> determine whether it's closer than the head and use
> it if it is?
>
> > Add(index, item)
> > - Reset trackingIndex, trackingNode
> > - Do normal add.
>
> That's one way to do it, you could also set the
> tracking node to the last added also.
Could be.
But I was focusing on your statement where you said it wasn't feasible. It is. And easily so. And I was providing examples of how it could be done (other modifications would/could also be required.)
> > No, get() must be noted if the list has been
> > restructured between calls.
>
> That still requires writing code in other methods.
> Otherwise you introduce a bug. You can't modify
> y get(int) only. You have to add code to reset this
> when the list is modified.
Sure, but it's quite likely that this information already exits in the form of a private method in LinkedList you can call from get(). So an educated guess would be that only get() would have to be modified. I don't understand why you consider it so important that this optimization must be implemented strictly local to get()?
> Sure, but it's quite likely that this information
> already exits in the form of a private method in
> LinkedList you can call from get().
No. Not as such. You need to save a separate state.
> So an educated
> guess would be that only get() would have to be
> modified.
If you saved the last modCount separately and checked it each get call and reset it when it needed to start over I suppose you could do that.
> I don't understand why you consider it so
> important that this optimization must be implemented
> strictly local to get()?
It's not. My point was that you assumed that it was done, then made it sound like it was an oversight. As far as I am concered, it's an unecessay complication that is only desirable when one is obsessed with micro-optimizations.
>
> It's not. My point was that you assumed that it was
> done, then made it sound like it was an oversight.
> As far as I am concered, it's an unecessay
> y complication that is only desirable when one is
> obsessed with micro-optimizations.
From where I sit, it would appear that Sun, has spent a bit of time mucking about in the core api to get to run faster via micro-optimizations.
Or at least I hope that is the reason.
> It's not. My point was that you assumed that it was
> done, then made it sound like it was an oversight.
> As far as I am concered, it's an unecessay
> y complication that is only desirable when one is
> obsessed with micro-optimizations.
So it's that old micro-optimization issue again -:)
I'm not obsessed with it, I've only asked will someone please stop just repeating the term and instead provide a definition. What is a micro-optimization? Would you really call optimization of the collections "micro" and "premature"? In my view if there's one place care should be taken to get maximum performance out of classes it must be the standard collections.
> From where I sit, it would appear that Sun, has spent
> a bit of time mucking about in the core api to get to
> run faster via micro-optimizations.
In some of it, in other parts, not so much, and then there's just poor code.
> Or at least I hope that is the reason.
I don't have that much faith.
> micro-optimization? Would you really call
> optimization of the collections "micro" and
> "premature"?
The micro-optimization is using a for loop and direct access instead of an Iterator.
> In my view if there's one place care
> should be taken to get maximum performance out of
> classes it must be the standard collections.
The optimization you suggest, while valid, it only really useful if one wants use a for loop with random access instead of the Iterator.
>
> > In my view if there's one place care
> > should be taken to get maximum performance out of
> > classes it must be the standard collections.
>
> The optimization you suggest, while valid, it only
> really useful if one wants use a for loop with random
> access instead of the Iterator.
Yes and no.
First the optimization only helps if one is using sequential access. So random access would nullify the point of doing it in the first place.
Secondly implementing it would also assume that people are likely to do that sort of sequential access in the first place. I would suppose most people are going to assume that the list is going to be using a first to last search (I for one wouldn't have even expected the divide by two optimization.) So they probably aren't going to rely on the get() method.
Finally it presumes that Sun really considers such decisions carefully. And I don't think they do. (As far as I can tell they toss stuff over the wall and take what ever comes back as long as it passes the test cases.)
> Yes and no.
>
> First the optimization only helps if one is using
> sequential access. So random access would nullify
> the point of doing it in the first place.
By 'random access' I mean accessing it by index. It's not necessarily 'random'. I think that's pretty common usage of the term. Random Access Memory doesn't have to be accessed randomly.
> Finally it presumes that Sun really considers such
> decisions carefully. And I don't think they do. (As
> far as I can tell they toss stuff over the wall and
> take what ever comes back as long as it passes the
> test cases.)
If you are saying I presume that I disagree. I'm presuming they don't. Adding this optimization would require considering how people use it and making allowances for 'mistakes'. Not doing it doesn't require extra thoughtfulness.
> > micro-optimization? Would you really call
> > optimization of the collections "micro" and
> > "premature"?
>
> The micro-optimization is using a for loop and direct
> access instead of an Iterator.
You're jumping freely between two cases; optimizations of the collection itself and optimization of the code that uses the collection.
If we discuss the optimization I suggested of LinkedList you can note (from the code you posted) that get() already performs an optimization. It decides if it's better to start scanning from the beginning of from the end. A LinkedList could easily also keep track of a current position and start scanning from there if it's favourable. This is basically what I suggested and it would be to take an optimization that's already in place just a little step further.
As long as methods are available people are going to use them. For example a sort() on a linked list is quite expensive, but if you clock a LinkedList against a corresponding ArrayList the timing is virtually identical. This suggests to me that an optimization is in place. The LinkedList is probably loaded into an ArrayList, sorted and then re-created again from the result.
I really can't see why you have trouble with quite sensible optimizations like this. Implementors have to consider the probable usage. If you can do get() and sort() on LinkedList people are going to do that (even though they should know both operations are theoretically slow).
> You're jumping freely between two cases;
> optimizations of the collection itself and
> optimization of the code that uses the collection.
Yes. One is an optimization and the other is what I consider a micro-optimization. Thr optimization mainly helps people who use the micro-optimization.
> As long as methods are available people are going to
> use them. For example a sort() on a linked list is
> quite expensive, but if you clock a LinkedList
> against a corresponding ArrayList the timing is
> virtually identical. This suggests to me that an
> optimization is in place. The LinkedList is probably
> loaded into an ArrayList, sorted and then re-created
> again from the result.
Close. it calls toArray(), sorts the array and then uses the ListIterator to set each element to the corresponding element in the array.
> I really can't see why you have trouble with quite
> sensible optimizations like this. Implementors have
> to consider the probable usage. If you can do get()
> and sort() on LinkedList people are going to do that
> (even though they should know both operations are
> theoretically slow).
I don't have a problem with the optimization per se. It's the suggestion that the implementation is flawed because it doesn't have it and the assumption that it would.
>
> I really can't see why you have trouble with quite
> sensible optimizations like this.
I have two problems...
First what is the normal and expected usage for a LinkedList? And what is the normal and expected usage for get()?
My assumptions about the class...
- I would expect that get() would only be used for random acccess - not sequential.
- If I wanted random access I would never use LinkedList in the first place, because I would 'expect' that such usage would be slow.
Given that I believe that the above is what anyone who knows how linked lists work would think it would suggest to me that there is no point in optimizing the get method (including the current optimization.)
(And if someone doesn't know what a linked list is then what are the chances that they are going to do something else wrong which would completely negate any advantage?)
Second any change like this requires time to implement, time to test and time to maintain. What about the other serious problems in the system?
The Sun VM still blows up. At least 1.4.2 does. I see no reason not to expect that 1.5 will also do so.
Do you really think that it is more important to have get() micro-optimized versus figuring out why the VM blows up and stopping that?
Not to mention that changes like this make bugs more likely. An 'optimization' in StringBuffer introduced a memory leak into XML parse engines which was evident for large files. It took something like 3 minor revisions to get it fixed.
Do you think that is worth it?
> > You're jumping freely between two cases;
> > optimizations of the collection itself and
> > optimization of the code that uses the collection.
>
> Yes. One is an optimization and the other is what I
> consider a micro-optimization. Thr optimization
> mainly helps people who use the micro-optimization.
The optimization we're discussing is already in place in principle (when get is called the implementation decides whether to start scanning from the beginning or from the end). To introduce a "current" position and start scanning from there when it's favourable is just to take the existing optimization a little step further.
> Close. it calls toArray(), sorts the array and then
> uses the ListIterator to set each element to the
> corresponding element in the array.
See. The LinkedList implementation already has many optimizations in place to overcome the theoretical limitations of a linked list. This is to be expected in industrial grade code.
> I don't have a problem with the optimization per se.
> It's the suggestion that the implementation is
> flawed because it doesn't have it and the
> assumption that it would.
I never said LinkedList is flawed just because an optimization I expected wasn't there. I also expected Mergesort to not be used and that time I was right. Unfortunately my psychic abilities sometime fails me. -:)
> > I really can't see why you have trouble with quite
> > sensible optimizations like this.
>
> I have two problems...
>
> First what is the normal and expected usage for a
> LinkedList? And what is the normal and expected usage
> for get()?
Yes but the expected usage becomes a little blurred if you consider the List abstraction. What's the normal and expected usage of a List?
The main problem is that the collections offers just two implementations of List and that those have very different characteristics. In this situation I think it's natural for ArrayList and LinkedList both to move somewhat towards the middle and/or that a DequeList is introduced to cover the middle ground for situations when you really want random access AND random inserts/removals equally bad.
> Second any change like this requires time to
> implement, time to test and time to maintain. What
> about the other serious problems in the system?
Sure, Sun has to cover a lot of ground to keep the Java platform competitive and that's a problem because they cannot afford to spend too much effort in any specific area.
As a complement third-party providers could come in and provide highly optimized versions of standard libraries, such as alternative collections. I don't know why this isn't happening but one reason may be that when Sun says 100% pure Java they really mean 100% pure Sun. *)
*) I also get the feeling this is how most programmers want it. Especially those who always bash Microsoft for its monopolistic tendencies -:)
> Close. it calls toArray(), sorts the array and then
> uses the ListIterator to set each element to the
> corresponding element in the array.
>
> > See. The LinkedList implementation already
> > has many optimizations in place to overcome
> > the theoretical limitations of a linked list.
> > This is to be expected in industrial grade code.
That optimization is done for all Lists which aren't RandomAccess Lists. It has a larger impact (theoretically, there aren't many non-RandomAccess Lists in common usage). Your optimization has a smaller impact, and is only needed when someone is too stupid to use an iterator. If someone decides to loop through a LinkedList by index, they deserve to have an order n**2 loop.
> > First what is the normal and expected usage for a
> > LinkedList? And what is the normal and expected usage
> > for get()?
>
> Yes but the expected usage becomes a little blurred
> if you consider the List abstraction. What's the
> normal and expected usage of a List?
>
> The main problem is that the collections offers just
> two implementations of List and that those have very
> different characteristics. In this situation I think
> it's natural for ArrayList and LinkedList both to
> move somewhat towards the middle and/or that a
> DequeList is introduced to cover the middle ground
> for situations when you really want random access AND
> random inserts/removals equally bad.
>
Ok I can accept that.
> > Second any change like this requires time to
> > implement, time to test and time to maintain. What
> > about the other serious problems in the system?
>
> Sure, Sun has to cover a lot of ground to keep the
> Java platform competitive and that's a problem
> because they cannot afford to spend too much effort
> in any specific area.
>
Sorry I can't agree with that.
Modifying get() for this optimization is several orders of magnitude less important than getting rid of the VM system exceptions.
> As a complement third-party providers could come in
> and provide highly optimized versions of standard
> libraries, such as alternative collections. I don't
> know why this isn't happening but one reason may be
> that when Sun says 100% pure Java they really mean
> 100% pure Sun. *)
There are at least two alternative collection libraries. One extends the current java collections and the other completely replaces it.
> Sorry I can't agree with that.
>
> Modifying get() for this optimization is several
> orders of magnitude less important than getting rid
> of the VM system exceptions.
I've never considered it my role to set the priorities for Sun. I didn't realize that my little optimization suggestion now is preventing them from solving bugs in the Java runtime system. Sorry for that -:)
> There are at least two alternative collection
> libraries. One extends the current java collections
> and the other completely replaces it.
One would be Jakarta, and maybe IBM offers something of their own. Well, then it's still possible that the get optimization is implemented somewhere.
If I had a saying though I would rather vote for a deque implementation of List (a DequeList) rather than the optimization we've been discussing here.
> It's not. My point was that you assumed that it was
> done, then made it sound like it was an oversight.
> As far as I am concered, it's an unecessay
> y complication that is only desirable when one is
> obsessed with micro-optimizations.
Micro-optimizations are necessary at the core level and in any high-use code path. I feel that if more people worried about performance at every level and during every phase of developement, performance would be a much smaller issue.
Yes, I understand that it's a huge grey area and can be over-thought and over-done -- creating more complications and bugs. I'm speaking "in general".
This thread has been a great read, in any case. Keep up the good work. :)
> Micro-optimizations are necessary at the core level
> and in any high-use code path. I feel that if more
> people worried about performance at every level and
> during every phase of developement, performance would
> be a much smaller issue.
The problem is that I see so much code that is meant to improve performance but really makes it worse and/or introduces bugs. I've never seen a performance issue that was a result of not doing some micro-optimization. I've seen many that were a result of poor overall design or lack of macro-optimization.
Most of the issues I run into are maintenance and correctness problems. I think if more people worried about making code robust and well-structured and less time worrying about many micro-seconds it takes a given loop to execute, would have a lot more time to do development instead of putting out fires all the time.
> The problem is that I see so much code that is meant
> to improve performance but really makes it worse
> and/or introduces bugs. I've never seen a
> performance issue that was a result of not doing some
> micro-optimization. I've seen many that were a
> result of poor overall design or lack of
> macro-optimization.
>
> Most of the issues I run into are maintenance and
> correctness problems. I think if more people worried
> about making code robust and well-structured and less
> time worrying about many micro-seconds it takes a
> given loop to execute, would have a lot more time to
> do development instead of putting out fires all the
> time.
I agree 100%.I guess I've run into too many developers who just throw out all thoughts of performance (both micro and macro) altogether, so I tend to lean a bit to the performance side (that and I was part of a performance improvement team).Can't seem to find enough people who consider both sides intelligently (code structure/archeture and performance).
> I agree 100%.I guess I've run into too many
> developers who just throw out all thoughts of
> performance (both micro and macro) altogether, so I
> tend to lean a bit to the performance side (that and
> I was part of a performance improvement team).
> Can't seem to find enough people who consider both
> th sides intelligently (code structure/archeture and
> performance).
I think a lot of the development problems I see are rooted in a lack of experience and lack of mentoring. Junior developers are too often left to their own devices with no oversight from more senior developers.
> The problem is that I see so much code that is meant
> to improve performance but really makes it worse
> and/or introduces bugs. I've never seen a
> performance issue that was a result of not doing some
> micro-optimization. I've seen many that were a
> result of poor overall design or lack of
> macro-optimization.
Sure but it still must be possible to discuss "micro" issues in isolation. It's wrong to use ones personal experience as a yardstick to judge whether an issue is "worthy" of a discussion. I have another experience than yours. In my (scientific type) application it's absolutely crucial that it's a) very fast and b) very "slick & smoth" to be competitive.
> Sure but it still must be possible to discuss "micro"
> issues in isolation. It's wrong to use ones personal
> experience as a yardstick to judge whether an issue
> is "worthy" of a discussion. I have another
> experience than yours. In my (scientific type)
> application it's absolutely crucial that it's a) very
> fast and b) very "slick & smoth" to be competitive.
I don't disagree with that. The point is that a lot of inexperienced developers will attempt to these optimizations without understanding that they rarely have a noticeable impact on the application performance.
Many times I have seen developers try to solve a performance problem in code.The first start doing things like unrolling methods. They might go after String concatenations (sometimes that is the problem.) Or perhaps they start eliminating Objects because 'OO is slower' and replace them with static methods and structures (or long parameter lists.) Then, after all of that makes no difference (or makes things worse) they get someone to look at it who points out that they are implementing a normally logN algorithm as a N^2 algorithm or they are going to the database every loop iteration of something silly like that. By then it's too late to revese all the damage and the whole program becomes a kluge. I've had people rip apart my code without consulting me in order to do this kind of 'optimization'.
For this reason it makes sense for myself and others to question the motives of people asking these types of questions. In our experience, this kind of quesion spells trouble because it's normally rooted in misconceptions.
Lets say, for example that ammonia and chlorine bleach mixed together are a much better cleaning agent than each separately (I don't know whether this is true, it's just an example.) And lets say this was a cleaning forum and someone asked, "Will mixing bleach and ammonia make a superior cleaning agent?" We could just say yes. We answered the question. But don't you think it would be considerate to mention that doing so could produce dangerous amounts of deadly chlorine gas? Perhaps the person will do this under a hood and understands the risks and precautions. But we don't know that. It's irresponsible to guide someone towards something dangerous without mentioning the danger.
> It's
> irresponsible to guide someone towards something
> dangerous without mentioning the danger.
The OP ask which is faster. To loop through an ArrayList using index or an iterator.
The first reply was,
"The average person lives about 80 years, figure 254608000000 milliseconds, counting leap-years. Fact is, you've spent more time asking this question than it will take you to run those loops.
In short, Premature Optimization is the Root of All Evil."
You see this type of answers all the time when someone asks a performance related question. This is no guidance. This is a pompous put down without any value whatsoever.
> You see this type of answers all the time when
> someone asks a performance related question. This is
> no guidance. This is a pompous put down without any
> value whatsoever.
I forget how we got here and I don't feel like going back to re-live it. I see what you are saying but I think it's perfectly reasonable to point out that focusing on uneccesary (and often misguided) optimization tends to lead to a poor code-base.
> > You see this type of answers all the time when
> > someone asks a performance related question. This is
> > no guidance. This is a pompous put down without any
> > value whatsoever.
The guidance is that it hardly matters which you use. Which was the best advice I could think of giving at the time.
~Cheers
> > > You see this type of answers all the time when
> > > someone asks a performance related question. This is
> > > no guidance. This is a pompous put down without any
> > > value whatsoever.
>
> The guidance is that it hardly matters which you use.
> Which was the best advice I could think of giving at
> the time.
It hardly matters? Of course it does! The two loops are at different abstraction levels and there's a performance issue involved.
Stop saying that things doesn't matter when they do and stop throwing around that "Premature Optimization is the Root of All Evil" advice when you don't understand it.
