Don’t Trust Error Messages

I just spent some time chasing an error message that I was getting from a Windows Media component when I tried to open a Windows Media Stream. The error was NS_E_BAD_CONTROL_DATA which is defined as:

The server received invalid data from the client on the control connection

This is a very cryptic message because when dealing with COM objects, the terms “Server” and “Client” can have many many meanings. In this case, I had no real clue whether it was referring to a conventional network Server and Client or a COM server and client. That threw me off for a bit.

I ended up finding the problem and it wasn’t even remotely close to what the error claimed. The problem was that my destination folder where I planned on recording the stream TO didn’t exist. Yeah it’s a stupid mistake but what does that have to do with reading the stream? Remember it was WMASFReader that died not WMASFWriter.

In any case, it’s important to remember that sometimes errors will occur and they will not be caught for quite some time or sometimes not at all. If their effects cascade throughout your program, you may find them causing errors that don’t make sense. If you could peel back the layers of the onion enough to see Microsoft’s underlying code, maybe the error and how it got there would make sense however on the outside, they’ll often seem unrelated and can be VERY misleading.

Do NOT fixate on what the error SAYS. Work backwards and find out what triggered it.

More X-Code Ranting - and Tips

I have in the past been a big CodeWarrior fan…here are some thoughts on transitioning to X-Code…(most of the credit must go to the DTS and Apple tools team for these tips…)

- Editor and code browsing…you can get X-Code to do almost everything CodeWarrior can in terms of useful code management. Command-double-click rather than option-double-click to jump to a definition, and the syntax coloring can’t color keywords, but finding symbols and jumping between source files is there.

- There’s a preference to make the layout look like a CodeWarrior project. I am trying to get myself used to the default view because it seems like it conveys more information in the long term. X-Code has a VC.net-like mode too in case you like pain.

- Compile is slow, but it’s also per-CPU and networkable. If you have a dual-core or dual-CPU machine, that’s a nice win and starts to close the gap. If you have a lot of headers, compile is actually faster than CodeWarrior when you crank the optimizers on both sims. (Warning: networked compile does not work between machines with different endian-nesses.)

- Once you understand the concept, preferences management in X-Code is definitely superior to CodeWarrior. In X-Code, every setting is a key-value pair. The target preferences are layered on top of project preferences - any preference can be anywhere. This means that you can factor the vast majority of your preferences out to your project, which simplifies making global settings changes.

- X-Code has a real concept of debug and release builds…in CodeWarrior if you have five applications that need to be debug, inlined debug, release, optimized release, and optimized universal release then that’s 25 targets. In X-Code that’s 5 targets and 5 build modes; most of the target settings are factored into the project anyway. The end result is a lot less setting check-boxes.

I’ll try to post more as I get there. Basically it only took one day to convert X-Plane from CodeWarrior to X-Code, and one more day to make X-Plane run on Intel Mac hardware.

The dangers of vector

Overall the STL has been a big win in X-Plane, but as I’ve worked on performance and optimization over the last week, some of the biggest wins have been from losing the STL and going back to older, simpler C structures.

The STL vector is a dangerous thing - most of the time it’s fast, efficient, easy to use, and simple enough that the compiler optimizes right through it. But when you have to build one up incrementally the performance is terrible.

The STL list can build up incrementally, but then for small objects you spend a ton on overhead for node pointer storage, etc.

So two things have worked well:

1. Simply adding a “next” pointer to small structures to turn them into an intrinsically linked list.

2. Using a memory sub-allocator. Our sub-allocator grabs a large chunk of memory, doles out small pieces (without tracking allocations — a high water mark just grows and we grab a new big block when we need one), and then the big blocks can be nuked en masse when we’re done with the whole subsystem. (Thanks to one of our users who I won’t “out” for suggesting this and design!)

In X-Plane we have to build up a lot of structures whose final sizes are difficult to determine, so these two ideas work well together; the sub-allocator is very fast for small allocations (the common case can even be inlined), and the overhead for the next pointer is reasonably painless. This scheme saved 25 MB just by applying it to the physical terrain triangle mesh.

(Another advantage of the intrinsically linked list: no need for a copy constructor or operator=, which might be difficult or undesirable to implement for a very complex heavyweight object.)

A final thought: putting 2 GB of RAM in your devepment machine might seem like a good idea, but it can be dangerous. Before I got the above scheme working my previous attempts to reorganize the code using STL vectors and lists bloated memory usage by 200 MB, and the performance hit was zero — the dangers of a G5.

PS Thanks to Chris for letting me glom up his blog.