For a long time it has been in the back of my mind to do some performance profiling to see what kind of overhead PithHelmet adds to Safari. Last week I finally sat down and ran some numbers.

I loaded about 40 web pages without PithHelmet and created a list of approximately 3700 unique urls. I build a small profiler into PithHelmet and ran these urls through the matching engine which determines whether or not to block a url. Using these sample pages (mostly news, sports, tech and entertainment sites) I determined that it takes ~0.002 seconds to analyze each url. After some tuning of the regular expression engine, I was able to drop that to ~0.0012 - about 40% better.

Either way, it's pretty clear that the matching engine is pretty speedy. On a typical page, PithHelmet adds about a tenth of a second to the total load time - a modest price to pay. However, this doesn't remotely paint the whole picture. When blocking is enabled, many of these sites load many times faster. Why? It's simple - most ad sites have awful response times. When a site has to load a tracking image from DoubleClick (one of the worst offenders) it hangs until the data has been returned. Most of the time this is within a minute - but that's a long time. The rest of the page has likely loaded within 2-5 seconds. If PithHelmet blocks that image, the page loads extremely quickly, saving the user nearly 55 seconds of boredom. If PithHelmet does this once a day, it has pretty much payed dividends on the measely tenth of a second it usually consumes.

Another long standing problem with PithHelmet has been the animated GIF performance. It was pretty awful and slowed machines to a crawl if you actually wanted your GIF images to loop. I've completely fixed this. It was actually really simple - the solution had just not occured to me until recently. I'd say this is well over 100 times faster.

Javascript is strange beast. I can't decide whether to love it or hate it. Regardless, Javascript is what powers the content collapsing. It checks the images and links on the pages to see if it should hide them from view. This used to be a crucial element to making the page look good, although in some recent tests, it seems slightly less relevant - I'm not sure if this is due to changes in ad layouts or web design trends. This is the single slowest operation that PithHelmet performs (a function of using Javascript instead of native code). However, after many hours of hacking, I finally figured out the problem (which I will relate in another article for those of you who care). Loading a page with ~2700 links (such as this month's GCC mailing list archive) used to hang for ~40 seconds scanning the links. I've got that down to ~1.5 seconds for the same page - thats about 25x faster (that is a lot). On a more typical page, the content scan takes about a tenth of a second.

Oddly enough, this also fixes the occasionaly "spinning pinwheel of death" problem by proxy since the long-running Javascript causes the application to temporarily appear hung. You have no idea how frustrating this was to find and fix, but the beast is finally slain.

To summarize, v2.2 FAST! Everything should be noticably more responsive. Some people will see incredible performance changes. I'm actually sorry I didn't do this sooner. I expect to spend a little time packaging up things, making sure I haven't broken anything and start a beta test shortly. Obviously, the beta will be available here only, not linked on the main page.