Jump to content
  • Advertisement
Sign in to follow this  
kalixxx

list.clear or new?

This topic is 3150 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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)

Share this post


Link to post
Share on other sites
Advertisement
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?

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
Um, yes. This is a good thing, because it's smarter than us, and has information we don't have.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by cache_hit
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.


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.)

Share this post


Link to post
Share on other sites
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:


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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!