Annocat: e pluribus unum

ElectricAccelerator annotation files are a fantastic way to get a grip on your build behavior and performance, but what if your Build (capital B) spans more than one invocation of emake? Annotation gives you a good look inside any single invocation, but there’s no way to get an overview of the entire process. You can’t just catenate the annotation files from subsequent emake runs — the result won’t be well-formed XML, and the timing information for jobs in each subsection of the build will reflect time from the start of that subsection, not from the start of the logical build. Plus, you run the risk of having overlapping job identifiers in different subsections. What you need is a specialized version of cat that is annotation-aware. In this article I’ll introduce annocat, a simple Perl script I wrote for just this purpose, and I’ll explain how it works.
Read the rest of this entry »

Just a minute!

How much is 'Compiling' costing you? (image xkcd)

How much is 'Compiling' costing you? (image xkcd)

Efficiency sure is popular, especially in the business of software development. NetApp would like to help you track storage efficiency. Nokia Siemens Networks hopes you’re thinking about network efficiency And Cisco points out that energy efficiency should be at the top of your cost-cutting strategy list.  Infrastructure vendors are on a singular quest to improve efficiency, and reduce cost.

Yet, by far the most expensive cost in software development is probably slacking off in the hallways, waiting for code to compile. Joel Spolsky – who writes the JoelOnSoftware blog, and manages the dev team at Fog Creek Software, recently wrote about his quest to shorten a thirty-second compile for the developers on his team. Thirty seconds! I have a hard time getting engineering managers to think about improving thirty-minute builds; reducing a thirty-second cycle time feels like an awfully small gain. Read the rest of this entry »

Delta: the coolest tool you’ve never heard of

One of the challenges that any developer faces is finding a small test case that reproduces a defect reported by users. That’s often easier said than done: when the defect originally shows up during parsing of a makefile consisting of 20,000 lines of nested calls to $(eval), separating the interesting lines from the irrelevant lines can seem like an exercise in futility. Thankfully, you don’t have to do it alone. Some clever guys at UC Berkeley wrote a tool called delta to assist with just this problem. In this post I’ll show you how you can use delta to distill useful test cases out of otherwise intractable inputs. The example involves makefiles of course, but the tool and the techniques are useful to developers and QA engineers in all fields.
Read the rest of this entry »