blogs > andrew > software > version-control > bzr-initial-commit-time

Thu, 20 Sep 2007

Incremental performance improvement

In passing in #bzr this afternoon, Robert Collins mentioned that he had dropped commit time for the example case he’s working on from 29.5 seconds to 18.8 seconds. Nice!

I asked him if this was towards improving the time taken to import new (large) projects into Bazaar? He said yes, but pointed out that some of this particular bit of optimization also impacts normal incremental commits and merges elsewhere.

It’s nice to see smart people working on things that benefit in not just one but many places. I wondered, though, how to quantify the sort of improvement that Robert is working on. The obvious target is the time taken to do the task being optimized. The broader question of knock on effects would rely on a broader performance measurement suite. It’s not a simple matter of “just make it run faster” — you have to be concerned that fixing one thing doesn’t make other important cases perform poorly as a result.

That reminded me that this is one of the things that db4objects is really good at. They continuously use their “PolePosition” benchmark system to evaluate the impact of changes and [hoped for] optimizations across a wide range of scenarios (read performance, write performance, writing in highly contended environments, etc) as evidenced by Carl Rosenberger’s recent work on improving transactional performance when db4o is being used in an embedded (single VM) environment.

Obviously, the cost of premature optimization is lost developer time spent working on things that don’t matter (if you’re lucky) and this risk of wrong architectural choices (which have much greater consequence). But design choices are unavoidable; you face them every day and then have to live with the consequences.

This isn’t “bad”; you make such decisions for good reasons. Some of the projects we’re doing for clients at the moment involves assessing the complexity of different architectural options and what impact those choices have on developer effectiveness, future maintainability, present performance and how hard improving it will be down the road. It’s interesting work.

This is one of the things I really respect about the team of people hacking on bzr. They took the time to map out a really sound architecture, and have worked hard on developing really robust algorithms capable of dealing with the complex corner cases that arise when doing merges and working with repositories with wildly different performance characteristics (branching locally versus branching from a repository half way around the world; are you using the dumb http:// protocol, or are you streaming at wire speed using the bzr:// protocol, etc). They took some heat early on because the consequence of their focus on architecture and robustness meant that some operations were rather slow, but they have been improving by leaps and bounds as they turn their attention from internals to performance. It works, it works correctly, and increasingly, it works fast.

AfC

bzr-initial-commit-time, posted by Andrew Cowie in /andrew/software/version-control at 07:05, 20 Sep 2007.

---

Category Specific Feeds. Use these links for an RSS or ATOM feed limited to this category and its descendants. Technorati Profile

---