A note on performance

In the 1.0 preview, AdblockIE ran most of the filtering asynchronously. That is, the webpage finished downloading, IE fired the "DocumentComplete" event, and AdblockIE spun off an asynchronous delegate to filter the DOM. This meant that, depending on threading considerations, the page could be loaded for a few milliseconds before it got fully filtered.

In 1.1, I did away with this, for the simple reason that my limited perf tests showed no advantage to this approach.

But with Apple, Google, Mozilla, and Microsoft releasing browser benchmarks every other week, you might be wondering what effect AdblockIE has on browser performance. I did a little bit of testing with the PerfTest BHO that's checked into the AdblockIE source tree. Unfortunately, as is often the case with this sort of thing, the results are far from conclusive.

In most cases, AdblockIE seems to add at most a few hundred milliseconds to total page load time. That's within the same order of magnitude as conscious visual perception, so probably not something to be too worried about.

On the other hand, there are pathalogical cases where AdblockIE can significantly slow down a page's load time. The New York Times Article Skimmer prototype is one such case, seemingly due to the weird and complicated JavaScript on the page.

Obviously I'm looking into these cases, and keeping IE fast is a big concern for me. (Unfortunately, the DOM-based filtering approach--which enables the NoScript-style JavaScript blocking--is inherently less efficient than simply blocking downloads at the HTTP layer.) In my very limited tests on the current alpha, I haven't seen any huge perf problems, or anything that indicates that this will be an architectural issue with AdblockIE. But we'll have to see how it scales when the ruleset grows, and see how it holds up on other machines and under other users.