| |
 |
Wednesday, June 12, 2002 |
.NET Framework FAQ updated today and includes us .NET Bloggers: Brad, Charles Cook, John Lam, Peter Drayton, Ingo Rammer, Drew, and Me.
Looks like they forgot Tomas Restapo, Justin Rudd, Simon Fell, Jim Murphy, Keith, Chris Kinsman, Jason Bock, Neils Berglund, Richard Caetano
That's 17, compared to only 15 reported by the Dark Side tonight-))
9:29:49 PM 
|
|
Drew has some excellent followup to the .NET Arrays article. Sam pointed out that Dr. GUI has put up Part #6 of his .NET series: "Arrays in the .NET Framework".
He covers a lot of good stuff, but the most important thing I think he points out is how allocation differs between value types vs. reference types.
Yes, I believe that an thorough understanding of value types vs. reference types is essential to every .NET Developer. MSDN has documented some Value Type Usage Guidelines. The ultimate explanation, IMHO, is the Richter chapter.
...it's important to note that you can actually get better perfomance by for'ing the array manually, like so:
for(int index = 0; index < myArray.Length; index++) { object o = myArray[index]; ... }
Not only does this avoid the overhead of IEnumerable and IEnumerator, but it also takes advantage of a little known Microsoft JIT trick which optimizes away bounds checking on the array. The only place I've ever seen the afforementioned JIT optmization documented is here in this article under the section titled "Use For Loops for String Iteration—version 1". From the section:
"The JIT is smart enough (in many cases) to optimize away bounds-checking and other things inside a For loop, but is prohibited from doing this on foreach walks. The end result is that in version 1, a For loop on strings is up to five times faster than using foreach. This will change in future versions, but for version 1 this is a definite way to increase performance."[Drew's Blog]
Cool! I knew about the IEnumerable and IEnumerator overhead but not the JIT trick. Thanks for the article pointer. I like these too:
-
Use simple structs when you can, and when you don't do a lot of boxing and unboxing. Tradeoffs ValueTypes are far less flexible than Objects, and end up hurting performance if used incorrectly. You need to be very careful about when and how you use them.
-
Use StringBuilder for Complex String Manipulation
When a string is modified, the run time will create a new string and return it, leaving the original to be garbage collected. Most of the time this is a fast and simple way to do it, but when a string is being modified repeatedly it begins to be a burden on performance: all of those allocations eventually get expensive.
Tradeoffs There is some overhead associated with creating a StringBuilder object, both in time and memory. On a machine with fast memory, a StringBuilder becomes worthwhile if you're doing about five operations. As a rule of thumb, I would say 10 or more string operations is a justification for the overhead on any machine, even a slower one.
-
Pick Data Reader Over Data Set When You Can
Use a data reader whenever when you don't need to keep the data lying around. This allows a fast read of the data, which can be cached if the user desires. A reader is simply a stateless stream that allows you to read data as it arrives, and then drop it without storing it to a dataset for more navigation. The stream approach is faster and has less overhead, since you can start using data immediately. You should evaluate how often you need the same data to decide if the caching for navigation makes sense for you. Here's a small table demonstrating the difference between DataReader and DataSet on both ODBC and SQL providers when pulling data from a server (higher numbers are better):
| |
ADO |
SQL |
| DataSet |
801 |
2507 |
| DataReader |
1083 |
4585 |
As you can see, the highest performance is achieved when using the optimal managed provider along with a data reader. When you don't need to cache your data, using a data reader can provide you with an enormous performance boost.
8:48:39 PM
|
|
Join Bobby Schmidt to learn the ins and outs of new Microsoft-specific language extensions in Visual C++ .NET in Optional Eqipment Package (June 11, 2002)
8:37:35 AM
|
|
8:35:34 AM
|
|
© Copyright 2002 Sam Gentile.
|
|
|
|
|
