I've been doing a lot of research into optimization strategies in .NET over the last couple of months, and given the fact that the platform is getting to be almost 7 years old, I thought it might be about due for a good, thorough book on the topic. I discussed it briefly with my boss today and he's interested.
For the record, I believe that it's critical to never sacrifice code readability for speed, so I won't be advocating those kinds of tasks.
But here's a partial list of topics I think I might cover (sorry, I couldn't figure out how to double-indent bullets):
- Intro: What you should already know
- Part 1: Optimizing memory usage:
- Controlling object lifetime while under the garbage collector
- Object reuse
- Managing duplicate references
- Part 2: Optimizing speed:
- Virtual and interface calling
- Delegates as an alternative to late-binding through reflection
- Part 3: Platform Invoke and Unmanaged Memory:
- Optimizing P/Invoke
- Common patterns for freeing unmanaged objects
- Critical finalizers
- COM interop objects
- Part 4: Special Topics:
- Visual Basic (for instance, using .NET patterns instead of VB-specific language features)
- ASP.NET (for instance, using constants instead of configuration settings and how it affects web site compilation)
- ASP.NET AJAX
- Silverlight
- Part 5: Tools:
- CLR Profiler
- Obfuscation tools
My question for everyone is: what kinds of things would you look for in a book that assumes you already have a working intermediate-level knowledge of the technology?
Well, since I don't have a working intermediate-level knowledge of .Net, you could assume that I wont buy it ;)
You might find it useful to spend a chapter on what algorithmic complexity is. I find that most people, while they do have a perfectly good understanding of what it is and why it's important, have no idea how to describe it, and don't understand the lingo that is most commonly used. It would be a shame to write a whole book on performance, only to have it fly over the heads of its readers.
The common denominator in the popular books around here is that the examples are simple and intuitive. It would seem that software developers tend to have a certain learning style whereby the examples are more valuable than body of text describing it; if they're overwhelmed by the example, they may not even read the description.
Quote from: MyndFyre on August 26, 2008, 04:03:35 PMFor the record, I believe that it's critical to never sacrifice code readability for speed, so I won't be advocating those kinds of tasks.
Never? You sure you don't want to add some qualifiers to that statement? There are absolutely cases where speed is more important than readability, but the occurrence is so low that it's reasonable to not address them.
Quote from: Camel on August 26, 2008, 05:13:06 PM
Well, since I don't have a working intermediate-level knowledge of .Net, you could assume that I wont buy it ;)
Awww, c'mon, even if it said, "Dedicated to Camel" in the front?? (Yeah, right)
Quote from: Camel on August 26, 2008, 05:13:06 PM
You might find it useful to spend a chapter on what algorithmic complexity is. I find that most people, while they do have a perfectly good understanding of what it is and why it's important, have no idea how to describe it, and don't understand the lingo that is most commonly used. It would be a shame to write a whole book on performance, only to have it fly over the heads of its readers.
I think you're absolutely right. That might go into the "Things you should already know" section. I wouldn't really call that section that name, but make sure it's a kind of "bringing everyone up to the same page" section or something.
Quote from: Camel on August 26, 2008, 05:13:06 PM
The common denominator in the popular books around here is that the examples are simple and intuitive. It would seem that software developers tend to have a certain learning style whereby the examples are more valuable than body of text describing it; if they're overwhelmed by the example, they may not even read the description.
So this was a little fuzzy to me; there should be more examples, or fewer examples?
I imagine a lot of what the book will be about will be "Consider this typical solution to this problem; here's what's going on behind the scenes and what you can do to make it faster."
Quote from: Camel on August 26, 2008, 05:13:06 PM
Quote from: MyndFyre on August 26, 2008, 04:03:35 PMFor the record, I believe that it's critical to never sacrifice code readability for speed, so I won't be advocating those kinds of tasks.
Never? You sure you don't want to add some qualifiers to that statement? There are absolutely cases where speed is more important than readability, but the occurrence is so low that it's reasonable to not address them.
Well like most absolutes, of course there are exceptions. But as you say, these are exceedingly rare.
Dedicate it to x86, or we'll come and kill you.
Quote from: Blaze on August 26, 2008, 06:15:46 PM
Dedicate it to x86, or we'll come and kill you.
LOL I could see that. "Dedicated to x86" in the front. intel calls me and thanks me....
Quote from: MyndFyre on August 26, 2008, 05:27:24 PM
Quote from: Camel on August 26, 2008, 05:13:06 PM
The common denominator in the popular books around here is that the examples are simple and intuitive. It would seem that software developers tend to have a certain learning style whereby the examples are more valuable than body of text describing it; if they're overwhelmed by the example, they may not even read the description.
So this was a little fuzzy to me; there should be more examples, or fewer examples?
I imagine a lot of what the book will be about will be "Consider this typical solution to this problem; here's what's going on behind the scenes and what you can do to make it faster."
I'm not particularly speaking of the quantity, but the quality of the examples. The quantity will be necessarily based on context, though I'd stress that you shouldn't overdo it. I've had at least one experience with a book whose examples almost always came in pairs, splitting the ideals which I was expected to uphold across two separate programs, and thus encouraging me to think it was impossible for them to coexist.
That is not to say it's bad to have multiple examples; in fact one of the most valuable books I've ever read (at the time, of course) was the one my dad bought me in grade school on HTML. It had two examples for every exercise: one with the topic at hand isolated, and another that was slowly built up throughout the book. Needless to say, everything about HTML in that book would be useless by today's standards. :)
Quote from: MyndFyre on August 26, 2008, 05:27:24 PM
Quote from: Camel on August 26, 2008, 05:13:06 PM
Well, since I don't have a working intermediate-level knowledge of .Net, you could assume that I wont buy it ;)
Awww, c'mon, even if it said, "Dedicated to Camel" in the front?? (Yeah, right)
If it was truly dedicated to me, I'd expect to get a free author's copy. Then I might skim through it, but I still probably wouldn't read it unless I got seriously involved in .Net for some reason. :)
I'd buy a copy. Dedicate it to x86.