Martin Parry

Debugging FileNotFoundException

martin — Fri, 15 Aug 2008 15:54:03 GMT

Recently in our app we were getting a System.IO.FileNotFoundException. The trouble was, the exception detail didn't tell us what particular file was missing. Our .NET app has a dependency on a COM DLL, which in turn has good, old-fashioned, dynamic-linkage dependencies on other DLLs.

Initially, I tried Process Monitor from sysinternals to log all filesystem access, but no joy there. This clearly wasn't normal File I/O, it was a module load that was failing. By the way, you can run those sysinternals utilities directly from http://live.sysinternals.com now, which is handy.

There might be a simple way to resolve this problem, but I couldn't think of it, so I resorted to a fairly obscure method, involving WinDbg. When I was at Microsoft we used to joke that Microsoft really has only one tool, and WinDbg is it. You can do everything in there. It's not easy to get started with it, but I do recommend persevering. It's best if you work near someone that already knows it, and get them to show you.

I guessed that the failure was occurring in a call to LoadLibrary or LoadLibraryEx, so I wanted to put a breakpoint on those functions and look at the string that was passed in - the name of the module to load. Here are the commands I entered into WinDbg...

bp kernel32!LoadLibraryW "r $t0 = ebp+8; r $t1 = @@c++( *((long *)@$t0 )); dc $t1 L64; g"

bp kernel32!LoadLibraryExW "r $t0 = ebp+8; r $t1 = @@c++( *((long *)@$t0 )); dc $t1 L64; g"

Each command sets a breakpoint in the relevant function, and defines a command to run when the debugger hits that breakpoint. In each case I find a pointer to the first parameter (which is at ebp+8), then I dereference this pointer and dump out 64 characters found at that address. The final "g" is to make the debugger automatically continue from the breakpoint.

What did this achieve? Well, running the app in the debugger dumped out all the names of the modules that were loaded by these two functions. When the FileNotFoundException was thrown, I just had to look at the most recent filename dumped out and that was the module that failed to load.

Almost done, but not quite. The name I just found is of the module that couldn't be loaded, but it could be found alright. Let's call it "banana.dll". It couldn't be loaded because it had a dependency on another DLL that couldn't be found. To find out what that might be, I did a "dumpbin /imports banana.dll". That told me what DLLs are imported by banana.dll. I just had to look through that list to find the one that was missing from my filesystem.

This is a case of "blogging for posterity" in case I ever need to do this again. Hopefully others can benefit from it too, though :-)

Finally, I have to question the wisdom of using FileNotFoundException to represent module load failures. No wonder the exception detail couldn't tell me which file was missing. Perhaps there should be a separate exception class for this?

On the Nature of Blogging

martin — Fri, 08 Aug 2008 13:55:48 GMT

When I look at the viewing statistics for my blog I see that last month was the biggest month ever, in spite of the fact that I didn't post much, and that I was on holiday for half of the month. Actually, there was quite a big increase compared with the previous month. This leads me to suppose that blog stats can only ever go up.

When I worked at Microsoft, "the management" collected bloggers' stats each month. In fact, it was a key metric that our performance was measured on, and one that I never excelled in. I don't think I'm giving away any secrets there. Sure, when you read a blog that's from a Microsoft employee you can probably expect that blogging is a part of his/her job that they're measured on, but that doesn't make the blog less valuable. Although there are a few worthless ones :-)

In general I think bloggers are seen as people donating their knowledge out of a spirit of generosity, and for a great many that is so, but you should always keep in mind that quite a few blogs are created and maintained just because the boss says so.

I'm sure other technology companies encourage blogging among their staff too. This is not a "Microsoft is evil" post. Blogging has become a very important marketing channel for technology companies.

The good news is that most bloggers who do well at achieving high stats do so because their content is high quality and they keep it coming at a prodigious rate, whether or not their boss is keeping score. But I must say I have known a couple of blogs that managed to achieve high numbers without seeming (to me) very worthwhile. There are all kinds of tricks a wise blogger can carry out that will hugely inflate their stats, more quickly than generating a lot of useful content that a lot of people want. Unfortunately, many employers can't see beyond the raw numbers. Quantity beats quality every time.

When you're reading blogs, why not see if you can tell whether the blogger is playing a numbers game...?

Visual Studio and Stability

martin — Wed, 09 Jul 2008 11:33:00 GMT

I was just reading the lastest MSDN UK Flash newsletter, and was very interested in the survey results. For the uninitiated, each issue of the Flash contains a survey that readers can respond to. In the next issue, they show the results of that survey. The most recent survey question was "What would interest you most around new versions of Visual Studio?" and the largest response (34%) was for "Stability, Reliability, Performance". I find this quite surprising.

In the 8 years I worked at Microsoft, I went through several versions of Visual Studio, including pre-release builds a lot of the time, and I must say I always found its stability and reliability pretty good. Performance was never a problem for me either. This was also true in my life before Microsoft.

But in all those roles I actually installed Visual Studio myself, from a disc or from the network using Microsoft's supplied setup.exe. In addition, I never had cause to install any non-Microsoft add-in for Visual Studio.

Recently I've been using Visual Studio on a machine managed by a customer of mine. They use a 3rd-party packaging system to deploy everything to their managed desktops. I don't know the details of how this works, but I'm guessing that it's some kind of registry/filesystem snapshot.

It's clear to anyone that's installed Visual Studio from a disc that the process is considerably more complex that dumping stuff straight into the registry and the filesystem. Maybe it shouldn't be - I could happily support that view - but it's clear that it is more complex than that. Otherwise why on earth would it take so long, and why would it display messages like "generating scripts"...?

So if we accept that VS is somehow "hard to install" we should probably believe that any 3rd-party packaging tool is unlikely to deduce all the correct logic to use when installing VS. In fact, I find VS decidedly less stable on this managed desktop than I've ever found it to be in the past, on systems where I used Microsoft's setup.exe.

Also, this managed desktop has several add-ins for VS installed. Occasionally VS has crashed and I've caught it in WinDbg, so I know it was at least one of the add-ins that caused the problem. I guess that VS has become a platform in its own right and people are blaming it for faults in components that they've installed on top.

Microsoft used to get the blame for all blue screens in Windows but I think these days most users realise that it's more likely to be a 3rd-party device driver at fault. Microsoft had to educate its customers by capturing data about their software failures and publishing data about the results. Kind of like "naming and shaming" except I don't think they ever published the names of the culprits.

I wonder how many of the survey respondents were using some "odd" deployment tool, or some 3rd-party add-in. Did they think about whose code was running when they experienced those stability issues?

So this survey result makes me think that perhaps the most useful features in future versions of VS would be to capture and publish data about which add-ins are crashing it, and to simplify the setup to the extent that a simple registry/filesystem snapshot is all you need to deploy it reliably.

Herding Sheep

martin — Tue, 24 Jun 2008 17:32:33 GMT

One of the things I find most interesting about software development is the people who do it. I think you can spot personality traits by reading people's code :-) A few years ago, I was introduced to the Myers-Briggs Type Indicator, and I was interested that it seems to categorize people according to 4 axes. I was a little dismissive of it at the time because, of course, a personality is more than 4-dimensional. But as time has passed, and I've met more software developers, and read more of their code, I've started to realize that there are common traits, and there probably are ways to categorize developers.

I should say, this is just idle chat. I am not suggesting that there's anything useful to be gained from this sort of analysis. I just find it interesting. In particular, I don't much care for the idea that an employer might try to assemble a team based on different types. But some days, a difference between types of developer hits me right between the eyes, and today is one such day.

Have you ever read some code and found a comment like "was getting unexpected exceptions here, but with this Sleep(500) it works ok". To my mind, the person who wrote this didn't feel in control of the machine. It's like "one man and his dog". I mean, the shepherd and his dog might consider themselves to be in control, but in reality the sheep have brains too. Ultimately it's their decision whether they walk into the little pen. I guess their thought process is something like "I might as well go where he wants, otherwise it's another 15 mins of being chased around the hillside".

But computers are even more stupid than sheep. You can try to coax it into doing what you want with little things like Sleep(500), but it has no concept of "you've been debugging me for hours now, I'll just give in". So coaxing and goading a computer into doing what you want is not an effective approach. You need to grab hold of it and make it do your bidding. Instead of the Sleep(500), when the exception happens, debug it. Find out exactly what's happening and then stop it happening. Master the machine.

So some developers are masters of the machine, while some are shepherds. In truth, I don't think it's a binary choice, it's more like a spectrum; master at one end, shepherd at the other. So...

M <------|------> S

...whereabouts would you put yourself on that spectrum?

SQL 2008 and SQL Compact 3.5

martin — Fri, 20 Jun 2008 12:33:17 GMT

I've been using SQL Server Compact Edition v3.5 for a little while now, and while the database engine has performed faultlessly so far, the same cannot be said of the management tool that's built into VS2008. Perhaps that has improved with SP1 of VS2008, I haven't checked yet.

Today, I downloaded the release candidate of SQL Server 2008, just to get the management tools and see if I can connect to my SQLCE3.5 database from there. I can, and it seems to work well. I must say that I haven't spent long working with it yet, but it's great to have access to some of the features I'm familiar with from "normal" SQL Server, such as a graphical view of the execution plan.

Of course, it's still a release candidate. My early optimism might soon wear off :-)

DesignMode in Windows Forms control development

martin — Tue, 17 Jun 2008 13:21:00 GMT

I'm currently working on an app that has to run on v2.0 of the .NET platform (with no SP applied). The particular behaviour I'm talking about may have changed in more recent versions - I haven't had time to check - but I was struck by something and just had to write about it.

When you're working on a UserControl, Visual Studio sets the value of a property DesignMode to true whenever it loads your control into the visual designer. This allows you to ensure that any code that depends on runtime artifacts doesn't run in the designer. But if you search, you'll find lots of folks bemoaning the fact that DesignMode isn't set before the constructor of your control runs. Again, maybe this has changed, I should check...

That means you have a problem if code in your constructor depends on constructs that are only available at runtime. There are a number of workarounds posted on the web, but none of them struck me as very nice, and some just didn't work for me. So I did the "obvious" workaround. I took the code that couldn't run in the designer, moved it out of my constructor and into a separate function, and did a check for DesignMode there. It works fine.

Now my control has a simpler constructor. It just initialises fields with values that are always the same. All the logic that calls into other parts of the app has been moved into my new function. I feel that my control is somehow "less-coupled" to other parts of the app now that I can construct it without those things being there. It feels more correct.

What's the catch? Well, something has to call my new function. That could be the code that instantiates my control, or I could call it from my own control's Load event handler, or from some other event handler inside my control. In my case, I chose to let the calling code do it. it worked fine but I still walked away thinking I'd made my codebase more complex to workaround an "issue" in VS2005.

But today I was doing further development against my control. It struck me that the additional function I introduced has actually allowed me greater freedom in the way I initialize the control and has actually simplified my codebase in the end. The feeling of correctness I got from refactoring the constructor was borne out in my ability to reuse this control in ways I didn't anticipate.

There's a lesson in that. You might feel coerced into writing code a certain way, just to workaround a quirk in your tools or platform, but that doesn't mean the workaround is actually worse than what you originally intended. It could be better.

The Campaign Against .NET Obfuscation

martin — Fri, 13 Jun 2008 12:27:53 GMT

I've started a one-man campaign. In fact I started it years ago when .NET obfuscation first appeared. I don't like any of the .NET obfuscation technologies. I don't think obfuscation is worth bothering with, and it makes the developer's life just a little bit harder. So don't do it.

Think about it...

1. Obfuscation is not encryption. That's really important.

2. People being able to see your code is not a bad thing most of the time.

3. If you have a case where it's really necessary to hide your code then, by definition, obfuscation isn't good enough. You need to encrypt that really sensitive piece of code, perhaps using something like Microsoft's SLPS. Even then, only encrypt the sensitive stuff, not the whole app.

4. .NET didn't change anything. Native code is not encrypted either. If someone can benefit from reverse-engineering your code, they are just as likely to do that to a native-code app as for a .NET app.

5. Obfuscation might deter the very casual observer, but how many casual observers fire up ildasm or Reflector? Honestly? And how much harm do you think casual observers will do to your business?

6. The ability to run ildasm and Reflector over my code is very useful to me, and makes me more productive.

7. Obfuscation might give your company a feeling of protection that it really doesn't offer.

8. No matter what the obfuscation-tool vendors do, the debug process is always slightly more complicated for an obfuscated app. If there was some value in obfuscating, this might be ok. But there just isn't.

Why I Don't Use Windows Forms DataBinding

martin — Fri, 13 Jun 2008 12:25:20 GMT

I have two reasons to eschew Windows Forms databinding. Complexity and Performance. As is usually the case, these two are related. You see, Microsoft designed databinding to accommodate a wide variety of controls, and an equally wide variety of datastructures. Because they couldn't predict exactly what we'd build, they designed a very flexible framework. But flexible often means complex, and slow, and in my opinion both are true here.

Controls and datastructures that are built into the .NET Framework typically "just work" when you bind them to each other. At least, that's been my experience. I think the same is true when you use controls that are supplied by any competent vendor. But if you try to create your own controls and datastructures and bind them together using Windows Forms databinding, you might find things get rather difficult.

As I've said before, don't use a tool if you don't understand what it does, and to fully understand Windows Forms databinding takes quite a bit of work.

Let's say you build a form and bind that to some complex datastructure of your own. First you have to understand databinding well enough to make it work as expected. Remember, you'll create the associations between controls on your form and data items in your datastructure, but the exact moment that values get copied backwards and forwards is not under your control. That single fact makes your code hard to maintain, in my opinion. Anyone trying to modify your form or your datastructure needs to fully understand databinding in order to know that it will continue to work as expected. And if at some point the binding isn't working as expected, someone will have to fully understand databinding in order to figure out where it's going wrong. Before you know it, everyone in the team has to understand databinding.

What's wrong with that? Well, surely to goodness the whole point of abstracting relationships between controls and data is to simplify. If everyone has to go and learn a somewhat complicated body of code in order to maintain your app, that simplification goal has gone awry.

Remember, Microsoft built databinding because they didn't know what types of controls, and what types of datastructure, we were going to create. To bind our controls to their data, or their controls to our data, we can use databinding. When we own the controls and the datastructures, we just don't need a flexible binding framework that can bind anything-to-anything. We can actually write obvious code that works intuitively to copy values from A to B. That might mean more lines of source code in our app, but it's a lot fewer lines of code being executed at runtime, and it's a lot more straightforward to maintain.

Ok, that's the complexity issue dealt with. I just want to say a little about performance. I accept that for most desktop apps Windows Forms databinding performs perfectly adequately. I happen to work on an app that's unusual in that, at times, it needs to update a lot of data on the screen very rapidly. I mean, much quicker than a human being can actually absorb. But we can't predict which value the user will want to look at, and when they look at it, it's got to be a very recent value. I mean, certainly no more than 100ms stale. If you know how Windows Forms databinding works, you'll know it doesn't lend itself to updating a lot of data that rapidly. This isn't a criticism of databinding, but it's worth knowing. I guess it wasn't designed to do this.

Because databinding towards the control is triggered from a property change in the underlying datastructure, any such change has to happen on the UI thread. You know you can't modify controls from some background thread. But when you're getting a lot of updates, you really need to minimize the work being done on your UI thread. I mean, it should really just be painting the screen and nothing else. I don't want to be managing my datastructure on the UI thread, rebuilding indexes and so forth. I want that to happen on another thread, then my UI thread can simply ask 10 times per second "what value should I draw here?". . And I certainly don't want to be creating objects to describe the property that just changed, simply to communicate that change to my control in a totally extensible and flexible way. I know what my datatypes are and I don't want to see source code that passes around property names as strings. That stuff just gives me the colliwobbles.

So there are two reasons why I'd rather not use Windows Forms databinding in my current project. The performance reason probably doesn't matter for most apps, and perhaps not for certain parts of my own app. The complexity reason on the other hand, well, that's the big one.

Simplicity in Software

martin — Fri, 13 Jun 2008 12:21:20 GMT

I think most of us developers would agree that keeping our software as simple as possible is a noble aim. I guess there are some developers who like to make things unnecessarily complex, but I for one hope not to spend too much of my life maintaining their code. I'm sure that no reader of my blog would fall into that category. No, we're talking about "other people" now.

Anyway, simplicity. What does that actually mean? I can think of a few definitions; I'm sure there are others...

1. Fewest possible lines in your source code.

I'm sure we've all seen those pathological examples where a whole lot of meaning is crammed into a few characters. Normally these examples are in C although I've seen good ones in Ruby and Perl too. So clearly simplest != fewest characters.

No, these things are clearly not "simple" in any practical sense. But, to some extent at least, trying to minimize lines of source code is a good idea. If you can make things clearer by removing code, do so. If removing code makes things less clear, don't do it.

2. Smallest amount of code overall.

I'm not talking about highly-optimized code necessarily. You could write few lines of source code yourself, but behind those few lines could be millions of lines of library or API code. People maintaining your code are probably affected by the complexity of code that yours calls, so it might be a good idea to give some thought to the particular calls you make and just how complex those implementations are. Of course, that has other benefits too.

3. Simplest logic.

Trying not to have too many nested levels of if/else with complicated, inter-related condition clauses. That's probably a good idea.

4. Most "obvious" code.

Is it better to have more lines of code that clearly copies values from A to B, or is it better to use some data-binding API that allows you to set up relationships between A and B, without knowing exactly when the values get copied? Me, I prefer to be in control and I'd rather suffer a few more lines of code if their meaning is explicit. Actually, Windows Forms data-binding is currently out-of-favour with me. I'll write about why in a separate post I think.

All my comments above assume that creating "simple" code is your top priority. In some cases other priorities come first and that's quite natural. Performance, security, or customisability could all lead to more complex code for example. But the goal of creating complex code for its own sake comes nowhere in the top-100 priorities of a software developer. If it's not already clear in your team, why not ask the person in charge to prioritize the various aspects that your system could exhibit...

1. Performance
2. Correctness
3. Maintainability
4. Security
5. Scalability
6. etc. etc.

...and assuming that Maintainability appears in their list, drill into that a bit further. Do they want the code to be "simple"? What do they mean by "simple"?

Rant about "Quiet Carriages"

martin — Wed, 28 May 2008 12:38:00 GMT

Moving away from my normal topic of software development, I just wanted to vent some annoyance about "Quiet Carriages". On the rail service I use, the operator designates 2 of the 8 carriages in the train as "quiet". They request that you don't use mobile phones or personal audio equipment in those carriages.

Now, here's a non-exhaustive list of the things that other people can do to annoy you while on public transport, in no particular order...

Hum or whistle a tune
Sniff loudly and incessantly
Clear the throat loudly and incessantly
Laugh out loud for no apparent reason
Rustle their newspaper
Get up and walk around for no apparent reason
Converse on a mobile phone
Converse with fellow passengers
Make lots of beeps from their laptop computer
Type loudly on their laptop computer
Eat smelly food
Suffer from unpleasant body-odour
Sit next to you and take up too much room
Listen to music through earphones that emit that "tickety-tick" noise
Spread their things all over your table
Tap hands or feet in time with some unheard music
etc. etc.

I've certainly experienced all of these things on British trains, and it didn't take me long to produce that list.

Why then would a train operator pick on just two of those potentially anti-social activities and forbid them in 25% of every train? I say potentially because I've certainly seen people use mobile phones responsibly - in silent mode, keeping their voice down, keeping calls short - and I've sat next to people using personal audio equipment that emitted no external noise detectable to me.

I've also seen a respectable-looking man run the length of a carriage to berate some unfortunate whose mobile phone rang in a quiet carriage. The poor guy didn't even answer his phone, he was just unlucky enough for it to ring, and he silenced it as quickly as he could. The elder vigilante wore a maniacal expression as he leapt into action and exclaimed loudly "this is supposed to be a quiet carriage". Now, whose action was the more distracting for his fellow passengers? In case you're wondering, the phone user wasn't me, but it might have been.

I use these trains during peak times, and frankly you're lucky to get a seat at all. For the train operator to suggest you have a choice of sitting in a quiet carriage or not is ridiculous. They just make no sense to me at all. I suppose most people of ticket-buying age can remember a time before mobiles, and before the walkman, so maybe this is an attempt to outlaw the new-fangled tools of distraction. I think when our children are grown up the quiet carriage will be a thing of the past, remembered as a quaint curiosity like when all cars had to be preceded by a man waving a red flag.

A lot of people either want or need to work while on a train, but surely most of those people work in open-plan offices? I can't believe a train carriage is a more distracting environment than your average office. Perhaps I'm lucky in that I'm able to switch-off from my environment, and so other people's phone calls don't distract me at all. Even if they did I'd have to accept that my distraction was at least as much my fault as theirs.

In the end, it's a sad commentary on our society that a train operator has to publish rules of politeness. I would be happier though if the rules were about courtesy and respectfulness in general rather than singling-out specific devices, and if we're instructing people on courtesy we should give equal effort to encouraging tolerance. It's a two-way street.

Consulting Nightmares: The Right Tool for the Job

martin — Thu, 15 May 2008 07:21:00 GMT

If I was a builder, and there was a tool in my toolbox that I didn't understand, couldn't tell you what it was for, then I think that tool would stay in the box. I wouldn't decide one day to get that tool out and start trying it out for jobs that I already knew how to do with other tools. I might go out of my way to find out what it's for, of course, but until I knew, I wouldn't be trying to use it. That's common sense I think.

Why then do we, as developers, often not apply the same logic to the "tools" at our disposal? I've seen more cases of this than you might believe, but here's one that stands out because I saw it so many times...

Many years ago, I attended the offices of an ISV to spend 2 days training them on COM+. I knew this ISV and I knew that they'd been using COM+ for at least 2 years. It might therefore seem odd that they wanted training on it now, but "better late than never" I supposed. I started by asking them some questions.

Me: "You decided to use COM+ then?"
Them (eagerly): "Oh yes, it was a no-brainer for our app, we knew we needed it."
Me: "Ok, who can start us off by telling me what COM+ is for?"
...Silence...
Me: "Well, you must have had a reason for deciding to use it?"
A lone voice from the audience volunteers: "Erm, transactions...?"

I can't be too hard on them. I mean, I'm sure that distributed transactions are the reason why most COM+ users came to it. It was a neat trick in its day. But transactions are surely not the heart of COM+. For me, it was all about the execution environment, the thread pool, the work queues, the ability to write STA components (in VB6 even) and have them run on a server. Run quickly and reliably. Whether they agreed with my answer to "what's it for?" is not the point. The point is that they had made a clear decision to use a technology, without being able to explain what that technology is for.

I know people aren't machines, and applying too much logic to human behaviour never works, but there's a distinct lack of common sense here I think. The reason I mention this stuff at all is that real software projects suffer and fail because of this sort of decision-making. The builder analogy works again...

I can use a hammer to bang a screw into a piece of wood, if I hit it hard enough. That doesn't mean a hammer was the right choice of tool. Had I chosen the screwdriver, my life would have been easier, and the results would have been better.

Don't think that this issue is obsolete because I used an older technology as an example. I still see it today. You might also choose to blame the developer marketing people: if they keep trumpeting Silverlight loudly enough, some folks are sure to try and build a device driver with it. I'm afraid it's our job as developers to see through the hype, and learn what all these tools are really for.

BOPS ?

martin — Wed, 14 May 2008 17:21:49 GMT

Earlier, I was looking at this page about quad-core processors from Intel. I know, I must have been bored :-)

Anyway, I spotted something interesting. Towards the bottom of the page, they publish numbers of "Billions of Operations Per Second", and they claim 153,500 of those BOPS. That's pretty impressive, I thought; over 150 trillion operations per second?

I followed their "more details" link, and on the next page BOPS was defined as "Business Operations per Second". That's a bit more believable :-)

Consulting Nightmares: XML

martin — Tue, 13 May 2008 07:09:00 GMT

In my consulting days, I had quite a few engagements where you might call me a performance troubleshooter. That is, the client had already built an app, in some cases it was even in the hands of users, but performance was unacceptably bad. They turned to their platform vendor for help, and they got me.

Performance is a feature, but it's an unusual one in that it can be present one day and so easily obliterated the next, sometimes by changing a single line of code. One technology stands out in my memory as being misused more than any other, and creating performance problems along the way. That technology is XML. This post from Jeff Atwood prompted me to think about this stuff again.

First, we should draw a distinction between the XML Infoset and the normal, textual encoding of XML that Jeff talks so eloquently about. Sure, we all think about angle brackets at the mention of XML, but data structured using the XML Infoset can be encoded in much more efficient ways. Note that WCF (in .NET v3.0 at least) uses XML to format all its messages, but can encode them in various different ways, so that performance can be just as good as Microsoft's older, binary, messaging formats. So it's really the textual encoding of XML that gives performance problems, but until recently I think that's all we had. Certainly I was never aware of tools on the Microsoft platform that did anything different.

Problems usually arose when XML was used as a mechanism for carrying lumps of data between modules, subsystems, call them what you will. Actually, let's think about that. Quite apart from any performance implications, is XML an appropriate "bag" to shift data around - often between components that are sharing an address space? Well, I'd never say "never", but it seems like an odd choice to me. I think in many cases development teams grew tired of typed interfaces between components and thought how much easier life would be if they could pass an XML string. You can put anything in there and it will still compile. That's right: turn all your compile-time errors into runtime ones. Smart move. Going way back I remember ADO Recordsets being used for similar reasons. Now, XML isn't necessarily untyped of course; we do have schema, but to do schema validation simply compounds the performance issues I'm mainly thinking about.

I saw two uses of XML that gave performance problems. One was where data was formatted as XML, with a textual encoding, into a string, then passed across some interface or other. This process incurs CPU overheads to format, encode, decode, parse, etc. and it's also pretty likely that there are memory overheads associated with transferring data in this way. I daresay though that plenty of systems out there work like this and manage to hit their performance goals.

The other, more interesting, scenario was where XML document objects were used rather than strings. I saw this done with msxml DOM objects and System.Xml.XmlDocument. The performance in these cases was usually significantly worse than for simple strings, although that does presume the strings were parsed using SAX or the XmlTextReader or similar, rather than loaded into a document object. The XML document objects are quite big, costly things. They maintain indexes across the data they hold, and they have to store the data in a way that allows them to easily read/write the textual encoding. Creating nodes in a document can typically only be done by making a call on a document object, so in some cases I saw people instantiating document objects simply to create nodes that could then be copied into other document objects. Once I saw around 80 document object instantiations to formulate a single data item that would more naturally have been a graph of typed objects. That's a lot of memory and a lot of CPU cycles.

That leads me to a simple statement that became something of a golden rule for me. If you're going to use a technology, understand it first. In other words, know what it costs.

It sounds so simple, but I'd say almost all the performance issues I ever saw could be traced back to a failure of this simple rule. The people who built those XML-centric systems weren't fools: if they only knew the cost of what they were doing, they'd have done things differently.

Today, I hope never to use code if I don't understand the tradeoffs involved. Does that mean I have to have source code for everything I use? No, although I use Reflector quite a bit. It also means that I experiment with alternatives. I build simple standalone apps to try out different algorithms and understand where they're strong and where they're weak. I've written before about "Big O" notation, and that's another big input for me when choosing data structures and algorithms.

For a long time, at least one of my fellow consultants held the view that XML is evil and should be banned. Of course, XML is a tool, and there are some jobs for which XML is the right tool. I think XML is unusual because, for a while there, a lot of people thought XML was the right tool for every job.

The Big O

martin — Thu, 24 Apr 2008 19:48:00 GMT

No, this isn't a post about Roy Orbison :-)

I consider myself lucky to have had what you might call a classical education in software. I mean, I was taught about principles rather than specific technologies. That means I was exposed to lambda-calculus, finite automata, turing machines, etc., rather than Visual Basic, for example.

I believe industry wants graduates to have been grounded in current programming technologies, but industry is wrong to want that. What industry needs is graduates whose skills are deeper than the flavour-of-the-month technology at the time of their graduation.

No offence if you belong to the newer school, by the way. Software development is a broad church, and all that.

Anyway, now to the point. One of the areas I studied was something called "Algorithmics", including algorithmic complexity. As part of this I was introduced to asymptotic notiation, or "Big O" notation. If you don't know it, Wikipedia has a pretty good introduction here.

My recent work has been focused on efficiently caching large numbers of objects in memory and indexing them in various different ways. I'm using C#. What's great is that the MSDN online documentation for the various collection types in the .NET Framework includes a description of the algorithmic complexity of the various operations. For example, it might state that insertion in a given collection takes O(log n) time, for collection size n. This knowledge is invaluable when trying to choose the right datastructure for the job. If performance is at all relevant to your work, I heartily recommend getting a thorough understanding of algorithmic complexity and "Big O" notation. Not only will you find MSDN documentation more useful, but it'll give you a valuable new way to think about your code.

Accommodating your Platform - OO Theorist vs. Windows Pragmatist

martin — Wed, 23 Apr 2008 16:12:00 GMT

In my years at Microsoft, I spent a lot of time in the performance and scalability lab, helping developers to achieve the maximum amounts of performance and concurrency in their applications. Because of all that experience, for me, it's a no-brainer that to make software systems work well you have to depart from your elegant OO-design at some point and start accommodating the specifics of your chosen implementation platform. I don't think this is obvious to everybody.

As a consultant, I've encountered some excellent OO designers and software architects who created OO models of their systems. Those models might well have been perfect in every way. Nevertheless, none of the mainstream platform vendors has yet perfected a way to execute those object models in ways that would be useful to our customers. Why is that? Because it's hard. Why is it hard? Because turning an OO model into code that will actually work well on a given platform depends on a highly-involved, intellectually-challenging process that developers carry out on a daily basis. Not to mention that it depends on information most people don't put into OO models, such as "where is performance most important: looking up the customer, or saving the customer's details?"

So I'd contend that the meaty part of a developer's job is actually figuring out how to make something work well on their chosen platform. OO models are an excellent piece of documentation that enable teams to share one view of their system. I'm all in favour of that, and there are other views of their system that developers could usefully share too.

You can look upon this as having to "spoil" a clean, elegant, model. But I could also say that a clean, elegant, model "spoils" a finished application if it doesn't work very well on your chosen platform. In most cases, the customer pays for the app, not the model.

I remember working with COM+, and MTS before it, where the platform dictated that you factored your code into COM objects based on their transactional requirements. Now, you could make those objects the same as the ones in your OO model, but if you did, performance would suck. Doing it well meant accepting that object factorization had real meaning to those platforms, and working with the platform instead of against it. The .NET platform is rather more forgiving. These days I don't think there are many sacrifices that have to be made to accommodate the platform, but I'm sure there are still some.

And it's not just about accommodating the platform. What about accommodating your team? You might very well choose to "spoil" your model so as to factorize the system in such a way that a team of people, maybe geographically dispersed, can efficiently collaborate on its development.

Developers have long been aware of the perils of a project plan. We've all worked for project managers that print out the plan and say "this is the truth, anything else is your mistake". In reality of course, the truth is what's in your version control system, and the plan is history as soon as it's been printed. That's not to say plans aren't useful. Clearly they are very useful, as a statement of where the team thinks it's heading.

I believe that OO design diagrams are very similar. Enormously useful as a shared vision of where the project's going. But probably inaccurate shortly after they've been distributed. The big difference is that project managers usually rehash the plan to accommodate new knowledge about the project, such as a specific task taking longer than expected. Designers seldom go back and change design diagrams to reflect code that's already been written.

This post is longer than I expected. I suppose it's turned into a treatise on the place and purpose of OO modeling in modern software development.