Awful Performance

Some time ago, a colleague of mine asked me to profile a collection of libraries, which had been provided by another vendor. One function received data over a TCP socket, and did some XML parsing. It seemed to perform weakly (100% CPU usage for several seconds even on a small size of data).

In this case we easily managed to improve performance by a factor of up to 30000. Workloads that took seconds or even minutes before now finish within some milliseconds. Here is what I did:

• Applying a standard XML parser instead of byte-wise self-implemented parsing.


• Buffering read data in byte chunks that grow dynamically by powers of two instead of concatenating single bytes to an MFC CString (the later implied constant reallocation of CString's internal buffer).


• One library was written in Java. The bytecode had been obfuscated. This included string constants, which were used inside the innermost-loop of the XML-parsing algorithm (these strings actually contained XML element names). Each time one of those strings was referenced at runtime, the inverse obfuscation algorithm was invoked on it - in order to "decrypt" the string to its original content. The performance impact was devastating - esp. as the "decryption"-algorithm was not really what I would consider lightweighted.


• Removing a memory violation, that the original vendor circumvented by delivering a debug version of one library. The debug version always protects the method-stack by some trailing bytes.

Joel On Software Book

I just received Joel Spolsky's new book from Amazon. This book mainly represents a "best of" Joel's website. I have been a loyal reader of Joel's weblog for several years and know most of his postings, which are full of deep insight into the business of software development. The Joel On Software Book is a unique collection of articles, and a lot of fun to read. I guess this clearly determines how I will spend the next couple of nights - reading with a flashlight under the blanket.

Pointy-Haired Boss Under Consulting Spell?

I mean it certainly makes sense to get help from external consultants e.g. from IBM when your department migrates its middleware to IBM Websphere, or from Microsoft if you are specifically interested in .NET Enterprise Services hosted by a COM+ application server. And I even understand the need for all those SAP or Baan consulting firms.

What I just don't get is why companies are so eager to spend weeks on explaining their business domain to a complete stranger (=consultant), who in exchange will charge them huge amounts of money either for a substrate of some outdated Gartner or McKinsey papers, or for pushing their own proprietary software solution, which doesn't even closely solve the technological problems the customer is facing.

I am talking about those guys who became consultants simply by printing their job title on a business card.

Why don't companies just instead give their own talented people some time and resources, and let them go figure out? Or as Wally would say: "Just because we pay inexperienced strangers to tell us how to do our jobs, that doesn't mean we're morons!"

First Posting

Welcome to Arno's Weblog. This blog is about software development, or to be more specific: the daily joy and pain of work as an ordinary software engineer.

While I don't expect too many visitors to be reading this, some people might find the content interesting or amusing. I am also planning to collect links to articles on more notorious software development blogs that might be of common concern.

By the way, I am not a native English speaker. So please forgive all those mistakes in my writings, that are certainly going to occur.