Pithy Perf Patterns

Achieving high performance with ASP.NET

James Geurts' Blog — Fri, 09 Jan 2004 20:06:00 GMT

re: Pithy Perf Patterns

Brad Wilson — Fri, 09 Jan 2004 22:01:00 GMT

I think I'd like an expansion on #9. It's hard for me to know whether Microsoft thinks I'm thinking or not. :)

We use XML for configuration files. Why? Because the XML parser is written. Writing parsers for text files is a lame way to spend your day.

re: Pithy Perf Patterns

Rico Mariani — Sat, 10 Jan 2004 01:23:00 GMT

It's funny how things work out. I suspect the email that Maoni sent Brad was distilled from the slides she and I made for a talk we gave together a few weeks ago which was in turn distilled from recent entries on my blog so I've already actually commented on most of those.

See http://weblogs.asp.net/ricom/

Now the particulars of XML and the XML DOM is that I often find folks picking up the (sledgehammer of an) XML parser to parse, at great expense, a comparatively small amount of data. Often precisely because it is so easy to do just that.

This isn't always the wrong thing to do of course; We each have to make choices as to where to invest our time, both processing time and development time. But, and this is especially true for simple configuration data, there are comparatively few benefits to using XML and the cost could be higher than you want to bear. So that advice makes our greatest hits list because it's a common pitfall. And not The Pit of Success.

So #9 simply boils down to make an informed decision. Doing anything by reflex is a recipe for Big Trubble.

re: Pithy Perf Patterns

Sat, 10 Jan 2004 03:58:00 GMT

Check out "Improving .net Application Performance and Scalability"

http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=540f8bd7-be95-45f7-a477-919d23294553

re: Pithy Perf Patterns

David Levine — Sat, 10 Jan 2004 11:42:00 GMT

>1. avoid finalizers; use the Dispose pattern

I'd expand this a bit. If an object implements the Dispose interface then it should also implement a Finalizer as a backstop, and then I would treat it as at least a warning (log it), and possibly an error (throw exception), if the finalizer ever ran. The idea is that the Dispose is a contract that the object requires the client to honor.
The goal is to catch violations during the debug phase before it ever ships to customers.

re: Pithy Perf Patterns

Brad Abrams — Sat, 10 Jan 2004 15:06:00 GMT

Thanks David -- I generally agree with your post, but I might not go as far as you suggest. The Dispose pattern is mostly a perf optimization... That is for correctness the finalizer running is not a bad thing so I would not throw and exception from the finalizer. The Finalizer is a great backup plan.
We know from experince with COM that developers have trouble explicily freeing instances, I don't want to go back to that world.. We should continue to take advantage of the GC here.

re: Pithy Perf Patterns

David Levine — Sat, 10 Jan 2004 17:02:00 GMT

Thanks Brad. Most of the subtle/weird problems we've run are at the intersection of .net and COM, and it's caused us to adopt a paranoid style with releasing resources, hence the rule I suggested. I completely agree that using the GC to free resources is far superior then relying on developer hygiene. But...

Currently we really can't go very far in .net before we have to interact with the underlying system objects (files, windows, networks, COM, threads, etc.) with open/use/close semantics. If all resources were managed we probably wouldn't need Dipose/Finalizers at all - try-finally blocks would handle most cleanup requirements. Until we reach that happy day we still need to use discipline. In our case we plan to surround the throw statements with #if DEBUG so that shipping code wont blow chow.

re: Pithy Perf Patterns

josh — Sat, 10 Jan 2004 19:17:00 GMT

but isn't the performance optimization of the suggested use of the dispose pattern over the use of finalizers that your objects don't have to be promoted in the GC so that at some time in the future the finalizer thread can come around and finalize them?

by putting in a "backup" finalizer it seems that you completly negate that optimization...

re: Pithy Perf Patterns

David Levine — Sat, 10 Jan 2004 19:47:00 GMT

The Dispose method calls GC.SuppressFinalize(this) so that the finalizer only gets called if the Dispose method is never invoked, so we still get our perf improvement if the object is used correctly.

re: Pithy Perf Patterns

Claude Ballew — Mon, 12 Jan 2004 12:32:00 GMT

I would have before a recent project completely agreed with you on ThreadPools instead of managing your own threads. In the Framework 1.0.3705 ( I have not tried the same with 1.1 or higher ) some interesting things happened inside of a Windows Service I had written.

The threads were in a thread pool using the Threading timer. The first thing I noticed was my first thread created was always favored. The other threads did receive clock cycles, but not as consistently as the first thread did.

The other thing that happened to me was a mis behaving DataProvider written by a non-Microsoft vendor who shall remain nameless :-) threw an unknown exception. This in itself was not a problem, but my next call into that provider went to never, never land. Again no problem except that at that point all my other threads stopped receiving clock cycles, no ticks ever fired again on any of the threads, but my primary thread and the service were still live.

I had much code devoted to handling awry thread, but that code never got hit because my app was unaware of the issue.

Now I have my own threads, spawned by me and a health thread to make sure all my threads are behaving and communicating in a timely matter and no more issues. I still believe in threadpools and I will probably try again in 1.1 to see if the same behavior is exhibited, but for my production code, I'll keep my approach until threadpools win me back.

Design Guideline Updates

Chris Burrows .NET Blog — Mon, 19 Jan 2004 13:00:00 GMT

re: Pithy Perf Patterns

eriksalt — Tue, 20 Jan 2004 15:13:00 GMT

I would like to see some more information on the threadpool requirement. Is the performance recomendation only because the threads are 'pooled', or is this a case like memory management where rolling your own tends to make things up? I have heard allot of talk refering to the threadpool as having performance limitations, and have seen developers in the field rolling their own threadpools. I think a more thorough treatment of this topic would enlighten many people.

re: Pithy Perf Patterns

Louis Parks — Sat, 24 Jan 2004 04:16:00 GMT

I must say it's a bit odd to hear someone suggest that using XML for a relatively small amount of data is not recommended. Visual Studio defaults all app config files to an XML format, all web app config files to an XML format, the VS project files to an XML format, etc. Often, these XML files hold very little data. Perhaps someone can clarify this for me?

Design guidelines from Microsoft

James Geurts' Blog — Thu, 29 Jan 2004 18:30:00 GMT

Microsoft Design Guidelines

James Geurts' Blog — Mon, 01 Mar 2004 20:34:00 GMT

re: Pithy Perf Patterns

Codezen — Tue, 02 Mar 2004 16:08:00 GMT

Regarding Louis Parks comment.....

It makes lot of sense to have config info in the XML file like app.config. The config file contains parameters that define the way an application would behave. E.g. a windows service that polls a resource at a configurable interval. If you need to to quicken up the polling, just change the config key, restart the service and thats it........now ain't that easy.

As far as perf is concerned....it is not that perf intensive. When an app domain loads, the config params are loaded in an in-memory collection by a section handler (parsing is done for that config section during this process) e.g. the keys in the appSettings section are handled by NameValueFileSectionHandler. So when you access these values, they are fetched from the in-memory collection.......no parsing here...so no perf issue.

Using the XML for data storage should be considered judiciously. Nothing like a good ol' RDBMS to store/manipulate/read the data. As far as data transmission is concerned XML can be a good idea e.g. if there is a case of transmission of data between two heterogeneous systems.

All and all Maoni's pt. 9 hits the nail on the head.

Casting in C#

Nick Parker — Fri, 04 Jan 2008 06:40:28 GMT

Casting in C#

Casting in C# — Fri, 04 Jan 2008 06:40:30 GMT

PingBack from http://www.developernotes.com/post/Casting-in-C.aspx

Brad Abrams Pithy Perf Patterns | Weak Bladder

Brad Abrams Pithy Perf Patterns | Weak Bladder — Tue, 09 Jun 2009 21:29:47 GMT

PingBack from http://weakbladder.info/story.php?id=6859

Brad Abrams Pithy Perf Patterns | pool toys

Brad Abrams Pithy Perf Patterns | pool toys — Thu, 18 Jun 2009 11:56:10 GMT

PingBack from http://pooltoysite.info/story.php?id=6918