list.clear or new?
what do you think will be faster (c#)
clearing a list or making a new one and letting the GC do it?
list<int> list = new list<int>();
void clrList()
{
list.clear();
OR?
list = new list<int>();
}
i ask this coz list.clear is an O(n) (well thats what msdn says)
if GC has to clear the list it would still be doing the same thing, and I would assume has the overhead of the GC.
It should be pretty easy to setup a test right?
It should be pretty easy to setup a test right?
the GC works when IT wants to work! its its own boss!
i can do 1000s of "new" and it will clean them when it FEELS like it!
i can do 1000s of "new" and it will clean them when it FEELS like it!
Um, yes. This is a good thing, because it's smarter than us, and has information we don't have.
MSDN also says that Clear does not cause any changes in memory allocation, whereas making a new list will make that old list available for collection and allocate a new one.
I think allocating a new one will be faster. In the long run the same amount of work will have to be done, but if all you're doing is orphaning one reference and setting it to another reference, that's going to be very fast in the short term, and the performance hit will come much later when the garbage collector thinks it's convenient and will have little impact on your program. With List.Clear() you take the O(n) hit immediately, garbage collection might be distributed over the idle CPU time.
The "O(n) hit" means they loop over the array and set each item to null. Then the size changes to 0. It's not exactly a huge operation.
Quote:Original post by Promit
The "O(n) hit" means they loop over the array and set each item to null. Then the size changes to 0. It's not exactly a huge operation.
Sure, I agree. But setting 100,000 items to null is still slower than what basically amounts to swapping one pointer.
Obviously it depends on the size of the list too. I wouldn't even be worrying about which is faster in the first place unless I profiled it and found that it was a problem, but I was just answering the question of which is faster :)
I could also be wrong, I haven't benchmarked anything, but it makes sense anyway.
Quote:Original post by cache_hitQuote:Original post by Promit
The "O(n) hit" means they loop over the array and set each item to null. Then the size changes to 0. It's not exactly a huge operation.
Sure, I agree. But setting 100,000 items to null is still slower than what basically amounts to swapping one pointer.
Thing is, newed arrays (like List uses internally) are also 0ed. Either you create the new list with the old capacity (in which case you're already paying the O(n) cost for zeroing immediately, on top of a later GC cost), or you eventually grow the list to the old capacity -- paying the zeroing cost later, plus zeroing a few intermediately sized arrays, plus GCing said arrays.
Basically, shit's getting zeroed, no way around it. In the unlikely event that clearing the list is causing, say, framerate stutter, re-new-ing the list is unlikely to solve the issue. Instead you'd have to roll your own List-alike to clear the list over a few frames (or not zero at all, but that'd probably be an incredibly bad idea leading to lots of unclaimed garbage spiking up your GC costs to the point where they might start causing frame stutter.)
I'm not disagreeing. And the growing is definitely something to consider when doing new List() instead of List.Clear.
I'm just saying, if all you're comparing is the instruction:
to the instruction
then the second one is probably going to return in a shorter amount of time. After that all bets are off. Whether or not this small of a speed increase is even worth worrying about is also a completely different matter. And it comes with tradeoffs such as the one you mention about inserts now causing re-allocations that would have not needed to be performed on the already existing list.
In my own code, I would probably write list.Clear(); because it's unlikely that such a micro-optimization would even help, and could potentially hurt. I certainly wouldn't even consider it without profiling first and making sure that list.Clear() was even a problem in the first place.
I'm just saying, if all you're comparing is the instruction:
l.Clear();
to the instruction
l = new List<int>();
then the second one is probably going to return in a shorter amount of time. After that all bets are off. Whether or not this small of a speed increase is even worth worrying about is also a completely different matter. And it comes with tradeoffs such as the one you mention about inserts now causing re-allocations that would have not needed to be performed on the already existing list.
In my own code, I would probably write list.Clear(); because it's unlikely that such a micro-optimization would even help, and could potentially hurt. I certainly wouldn't even consider it without profiling first and making sure that list.Clear() was even a problem in the first place.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement