More Performance Tidbits for library writers

re: More Performance Tidbits for library writers

Andreas Wölfer — Mon, 25 Oct 2004 22:40:00 GMT

Rico - thank you for that. Glad i was listening :)

re: More Performance Tidbits for library writers

Rico Mariani — Mon, 25 Oct 2004 23:27:00 GMT

Doh, it's Principle not Principal -- I noticed that when I first sent this out as email and then I didn't fix it when I posted it as a blog...

Thanks readers :)

The Seven (of n) Principles of Highly Effective Programmers

Zupancic Perspective — Tue, 26 Oct 2004 09:20:00 GMT

re: More Performance Tidbits for library writers

Stu Smith — Tue, 26 Oct 2004 10:24:00 GMT

Regarding point 5, it's a shame the compiler and BCL couldn't work together to handle this. Using foreach seems to me to be the natural way of iterating any array or collection, but it has this performance hit. ArrayList (for example) is virtual, yet I would have thought most people use it as-is. Perhaps if ArrayList had been ArrayListBase (abstract but with no abstract methods), with a sealed ArrayList derived from it, then the various compilers could have recognised that, and emitted an IL for-loop instead of a foreach. And surely arrays could be compiled in this way as the framework stands?

re: More Performance Tidbits for library writers

Rico Mariani — Tue, 26 Oct 2004 14:35:00 GMT

List<T> doesn't have this problem so hopefully people will be happy with List<Object> anywhere they would have used ArrayList going forward.

re: More Performance Tidbits for library writers

Omer van Kloeten — Tue, 26 Oct 2004 19:50:00 GMT

I'm with Stu on this. I actually wanted to say it myself, but Stu put it very well.
I think that the compiler could do a very nice job recognizing the BCL's collections. Since these collections have the overhead during foreach, but not during for, it could compile foreaches to fors.

You're saying "it'll be fixed for version 2.0", but we need it inside systems that are already in production with v1.1. Can something be done about this?

Also, could you elaborate on the "List<T> doesn't have this problem" bit?

re: More Performance Tidbits for library writers

Rico Mariani — Tue, 26 Oct 2004 20:03:00 GMT

Quoting myself from the Performance and Scalability PAG

Enumeration Overhead

The .NET Framework version 1.1 collections provide an enumerator by overriding IEnumerable.GetEnumerator. This turns out to be less than optimal for a number of reasons:

-The GetEnumerator method is virtual, so the call cannot be inlined.

-The return value is an IEnumerator interface instead of an exact type; as a result, the exact enumerator cannot be known at compile time.

-The MoveNext method and Current properties are again virtual and so cannot be inlined.
IEnumerator.Current requires a return type of System.Object, rather than a more specific data type which may require boxing and unboxing, depending on the data types stored in the collection.

As a result of these factors, there are both managed heap and virtual function overhead associated with foreach on simple collection types. This can be a significant factor in performance-sensitive regions of your application.

For information about how to minimize the overhead, see "Consider Enumerating Overhead"

The relevant section is:

http://msdn.microsoft.com/library/en-us/dnpag/html/scalenetchapt05.asp?frame=true#scalenetchapt05_topic25

These problems were all fixed in List<T> -- sadly we we're stuck with it in ArrayList because we'd have to break existing applications to fix it.

New

OdeToCode Link Blog — Wed, 27 Oct 2004 04:23:00 GMT

Amping up .NET performance

TrackBack — Wed, 27 Oct 2004 09:44:00 GMT

Weblogs.asp.net had a cool link to Rico Mariani's weblog that has a lot of good posts about tuning the most out of .NET applications. Some of the tips are pretty generic and can be applied to other programming languages and platforms as well. Specif

Performance Tidbits for Library writers

Martin's WebLog — Wed, 27 Oct 2004 11:44:00 GMT

Performance tips for library writers

Tiago Pascoal's WebLog — Wed, 27 Oct 2004 12:20:00 GMT

re: More Performance Tidbits for library writers

Joe — Wed, 27 Oct 2004 16:16:00 GMT

Isn't foreach on an array (not an arraylist, a real array) optimized already by the compiler? In fact it should be faster than using indexes because there won't be an around bounds check (which can happen for anything that the simplisting index based iteration).

re: More Performance Tidbits for library writers

Rico Mariani — Wed, 27 Oct 2004 16:36:00 GMT

Foreach on regular arrays gives you the best code. "For" on arrays often has no bounds check either if it's coded in one of the obvious safe ways.

Readings for 10.27.2004

The Diffracted Developer — Wed, 27 Oct 2004 20:34:00 GMT

Readings for 10.27.2004

The Diffracted Developer — Thu, 28 Oct 2004 01:24:00 GMT

re: More Performance Tidbits for library writers

Dmitriy Zaslavskiy — Fri, 29 Oct 2004 04:49:00 GMT

Rico could explain why does LinkedListNode stores back reference to LinkedList?
I am not asking why in term of implementation but rather in term of library design?
Why pay an extra pointer for each element.

In fact I would argue that a lot of the time people know that the objects they want to keep will go into this or that collection. Therefore they might be willing to derive from LinkedListNode to save on extra 12 bytes (+ allocations). Or maybe just to implement interface ILinkedNode ?

More Performance Tidbits for library writers

dotRob — Fri, 29 Oct 2004 16:00:00 GMT

I think I got it now

dotRob — Fri, 29 Oct 2004 16:02:00 GMT

More Performance Tidbits for library writers

dotRob — Sat, 30 Oct 2004 23:37:00 GMT

re: More Performance Tidbits for library writers

Arun Philip — Tue, 02 Nov 2004 08:47:00 GMT

Wow! Great points.

re: More Performance Tidbits for library writers

Rico Mariani — Tue, 02 Nov 2004 14:37:00 GMT

I'd like to remind folks of an important truth...

I only have two rules

#1 Measure
#2 Do your homework

"Don't use foreach" isn't in the list.

Better advice would be "foreach is good for everything but ArrayList" but even that isn't quite right...

#1 and #2 imply an important corollary --"Don't use pithy advice from so called experts (such as me) instead of doing your own measurements"

re: More Performance Tidbits for library writers

Ovidiu — Mon, 15 Nov 2004 16:24:00 GMT

As usual, a great post :) As for the "pretend that following a pointer is a very costly operation" part, I think the best picture one can get is by the following comparison:

<<Now 2GHz is a difficult thing to imagine for a human. Put simply that is 2 billion (Dr Evil pose) instructions per second at maximum throughput. So lets put this on our terms. Let's say once processor “clock cycle” is not 1/2,000,000,000 of a second but rather 1 second. On that scale accessing the nearby L1 on-chip cache takes 6 seconds, the off chip (L2) cache 2-3 minutes, and accessing main memory takes 3-4 weeks. Accessing the disk (just one disk access) by comparison takes a whopping 1 year on this timescale.>>

(From http://weblogs.asp.net/simonme/archive/2004/05/31/145024.aspx)