Ha ha, I came just to post exactly this. This seems like a cool product, and kudos to the OP for releasing it freely and as open software...but I'm considerably less inclined to trust software that uses such misleading copy. The fact that it is the very first benchmark listed is also not promising and makes me reflexively doubt the other benchmarks.
So what if they aren't? I haven't read the expressions in depth but they look like on a quick glance like they could be checked in linear time. It may have a high degree of branching, but so what when you are checking a single linear path through it for each URL?
This is correct. According to this article[0], posted in another comment[1], iOS 9's content blocker regular expressions are limited to a subset of regex for which matching can be done in linear time:
"Extremely powerful, regular expressions can surprisingly be done in linear time if you use a strict set of regular expression characters through Thompson’s NFA algorithm. Safari’s Content Blocker implementation in fact imposes this strict regular expression limitation ..."
Could you run the other ones as well? If you're positioning yourself as a faster alternative to ABP, it makes sense to compare yourself against other popular alternatives.
uBlock Origin is packaged with all the filter lists which are selected by default: EasyList, EasyPrivacy, Peter Lowe's, etc. This ensures that it will work out of the box immediately even if the respective remote servers are not responding, not an uncommon occurrence with the server hosting EasyList et al.
The size of the package is not a factor to performance -- removing EasyList, EasyPrivacy, etc. from the package would not make uBlock Origin faster or slower.
No one cares about 3 megabytes of disk usage. I did a quick memory "benchmark" for you. This is loading TechCrunch in 64 bit Chrome for Mac:
* uBlock Origin: 92,9 MB
* Adblock Fast: 54,7 MB
Considering uBlock Origin packs a lot of functionality (and lists) which your extension lacks, you don't really have much advantage (if any).
Also, consuming a "lower percentage of CPU" is counterproductive. Adblockers should peak the CPU for the smallest amount of time possible, not use a little percentage of CPU time during a longer period of time as you advertise. That's just ridiculous.
It's clear they haven't made a "better, faster" adblock, just one they can pass off as "faster" with misleading benchmarks all for the goal of not fighting on behalf of the user, but for advertising their app firm.
There are a whole lot of pitfalls to take care before comparing memory figures between two extensions, and in all my benchmarks I take care to avoid these pitfalls in order to not fool myself, as I use these benchmarks to drive development.
Simply bringing up the popup UI of an extension will cause temporary memory usage increase. Auxiliary extension pages will also cause temporary memory usage increase -- for example when uBlock Origin's logger is open. The process of updating filter lists also will cause temporary increase in memory usage. Garbage collection may take a while to kick in. Also, if one opens the developer console of an extension, memory usage for the extension may increase permanently despite the extension not having allocated any memory (I noticed this with the Element inspector).
How long an extension has been running also influence memory usage (memory fragmentation). What feature has been used will also cause jump in memory usage -- for example if a whole page has been blocked by uBlock, the look-up of the filter lists which contain the filter which caused the block will cause a Worker instance to come alive and linger in memory for over 10 minutes. Etc. etc.
I did not look at page load speed, but common sense is that the more resources are blocked, the faster page loads. ABP is probably also handicaped because it injects 14,000+ CSS rules before the DOM content is fully loaded (something not affecting uBlock Origin or Adblock Fast).
Methodology:
- Chrome 45 64-bit: only one tab open, "chrome://extensions" (click-to-play on. i.e. no Flash applet will run).
- Bring up the browser's Task Manager (Shift-Esc).
- Activate target extension (all other extensions are disabled).
- Adblock Fast: default settings (there are no settings).
- uBlock Origin: default settings = EasyList, EasyPrivacy, Peter Lowe's, Malware lists (this is a "mature" install, i.e. uBlock loaded its resources from a "selfie").
> In contrast, adblockers like Adblock Plus rely on javascript’s built in regular expression parser
This is not accurate for uBlock Origin. A majority of network filters in EasyList, EasyPrivacy, etc. do not need to be implemented as regular expressions, and for these uBlock Origin does not use a regular expression, it's simply a straightforward string comparison.
Also, there are further optimizations when a filter is just a hostname (these are common too, especially in HOSTS files which can be parsed by uBlock).
Adblockers and Noscript are not in the same category. Adblockers are useful for everyone, and shouldn't break things as long as the block list is well curated. Noscript is for highly technical users who know they're going to break many sites they visit and are prepared to deal with the pain of doing so and debugging the result because they consider it worth the cost.
This is not a valid Show HN until you have something for people to try out. People can't try out an email signup, which is why email signups are explicitly excluded by the rules:
Sure, but the story you submitted was "Show HN: Adblock Fast – An iOS 9 ad blocker", and there isn't an iOS ad blocker, only an email signup and a demo image. Unless I'm missing something, that's a plain violation of the most important rule.
Users email us to complain when they see posts that break this, because "Show HN" is an implicit contract that they'll be able to try a piece of software out. (The standards are looser for non-software projects.)
Understood, but the title got edited a couple times – could you edit back to something more neutral? (E.g., at one point the title was plain, old “Show HN: Adblock Fast”.)
There are three things at the top of page that are brand new and people can try out (plus we sent almost 100 copies of the iOS app so far to people who signed up this morning):
Ok, we've put the title back to "Show HN: Adblock Fast" and restored the post.
The logs turned out to be more complicated than I thought. You submitted "Show HN: A preview of our iOS 9 ad blocker". That did break the rules—a "preview" can't be a Show HN when the "preview" is an email signup and an image. A moderator changed that to "Adblock Fast", and then a moderator changed it to "Show HN: Adblock Fast – An iOS 9 ad blocker".
Since you do have new things for people to try out, though, it seems like making the title more general is the best solution.
Sorry, I'm not using an extension built for marketing your company, even if it is GPL licensed.
Also, I get that regex is how you do it on iOS9 and it's fast on there because of Apple's specific regex implementation, but you're misleading people that your 7 humongous regex are going to be faster than flagship blockers (uBlock Origin) on the desktop.
Yeah, I'd really like to see this benchmarked against µBlock Origin. I'm fine with switching if it truly is faster and works comparably, but until I see proof of that, I see no reason to switch over.
37 comments
[ 3.0 ms ] story [ 88.9 ms ] threadhttps://github.com/rocketshipapps/adblockfast/blob/master/op...
Are these regular expressions machine-compiled?
"Extremely powerful, regular expressions can surprisingly be done in linear time if you use a strict set of regular expression characters through Thompson’s NFA algorithm. Safari’s Content Blocker implementation in fact imposes this strict regular expression limitation ..."
0. http://blog.appgrounds.com/content-blockers-beat-adblocking/
1. https://news.ycombinator.com/item?id=10192562
https://www.raymond.cc/blog/10-ad-blocking-extensions-tested...
https://github.com/gorhill/uBlock/wiki/Blocking-mode
We didn’t benchmark uBlock [Origin], but I just ”ran” the filesize benchmark :-):
* uBlock Origin: 1.41 MB
* uBlock: 3.54 MB
* Adblock Fast: 96.59 KB
The size of the package is not a factor to performance -- removing EasyList, EasyPrivacy, etc. from the package would not make uBlock Origin faster or slower.
* uBlock Origin: 92,9 MB
* Adblock Fast: 54,7 MB
Considering uBlock Origin packs a lot of functionality (and lists) which your extension lacks, you don't really have much advantage (if any).
Also, consuming a "lower percentage of CPU" is counterproductive. Adblockers should peak the CPU for the smallest amount of time possible, not use a little percentage of CPU time during a longer period of time as you advertise. That's just ridiculous.
There are a whole lot of pitfalls to take care before comparing memory figures between two extensions, and in all my benchmarks I take care to avoid these pitfalls in order to not fool myself, as I use these benchmarks to drive development.
Simply bringing up the popup UI of an extension will cause temporary memory usage increase. Auxiliary extension pages will also cause temporary memory usage increase -- for example when uBlock Origin's logger is open. The process of updating filter lists also will cause temporary increase in memory usage. Garbage collection may take a while to kick in. Also, if one opens the developer console of an extension, memory usage for the extension may increase permanently despite the extension not having allocated any memory (I noticed this with the Element inspector).
How long an extension has been running also influence memory usage (memory fragmentation). What feature has been used will also cause jump in memory usage -- for example if a whole page has been blocked by uBlock, the look-up of the filter lists which contain the filter which caused the block will cause a Worker instance to come alive and linger in memory for over 10 minutes. Etc. etc.
Now using your TechCrunch example I get:
Adblock Fast: 20.8 MB + TechCrunch page itself: 75,4 MB = 96.2
uBlock Origin: 48,3 MB + TechCrunch page itself: 68,0 MB = 116.3
Adblock Plus: 77,7 MB + TechCrunch page itself: 85,5 MB = 163.2
I did not look at page load speed, but common sense is that the more resources are blocked, the faster page loads. ABP is probably also handicaped because it injects 14,000+ CSS rules before the DOM content is fully loaded (something not affecting uBlock Origin or Adblock Fast).
Methodology:
- Chrome 45 64-bit: only one tab open, "chrome://extensions" (click-to-play on. i.e. no Flash applet will run).
- Bring up the browser's Task Manager (Shift-Esc).
- Activate target extension (all other extensions are disabled).
- Wait 1 minute.
- Open new tab, paste "http://techcrunch.com/" in address bar.
- Wait 1 minute.
- Write down memory figures from Task Manager.
- Deactivate the target extension.
Details specific to each extension:
- Adblock Fast: default settings (there are no settings).
- uBlock Origin: default settings = EasyList, EasyPrivacy, Peter Lowe's, Malware lists (this is a "mature" install, i.e. uBlock loaded its resources from a "selfie").
- Adblock Plus: EasyList, EasyPrivacy, Malware list, "Acceptable ads" turned off.
> In contrast, adblockers like Adblock Plus rely on javascript’s built in regular expression parser
This is not accurate for uBlock Origin. A majority of network filters in EasyList, EasyPrivacy, etc. do not need to be implemented as regular expressions, and for these uBlock Origin does not use a regular expression, it's simply a straightforward string comparison.
Also, there are further optimizations when a filter is just a hostname (these are common too, especially in HOSTS files which can be parsed by uBlock).
My ff with no-script is 10-50 times faster than chrome on most of the websites. Should be safer too.
Is there any no-script options for iOS? (default with JS off but selectively turn on for just a few trust websites.)
Adblockers and Noscript are not in the same category. Adblockers are useful for everyone, and shouldn't break things as long as the block list is well curated. Noscript is for highly technical users who know they're going to break many sites they visit and are prepared to deal with the pain of doing so and debugging the result because they consider it worth the cost.
https://news.ycombinator.com/showhn.html
Users email us to complain when they see posts that break this, because "Show HN" is an implicit contract that they'll be able to try a piece of software out. (The standards are looser for non-software projects.)
There are three things at the top of page that are brand new and people can try out (plus we sent almost 100 copies of the iOS app so far to people who signed up this morning):
* https://chrome.google.com/webstore/detail/nneejgmhfoecfeoffa...
* https://addons.opera.com/en/extensions/details/adblock-fast/
* https://github.com/rocketshipapps/adblockfast
The logs turned out to be more complicated than I thought. You submitted "Show HN: A preview of our iOS 9 ad blocker". That did break the rules—a "preview" can't be a Show HN when the "preview" is an email signup and an image. A moderator changed that to "Adblock Fast", and then a moderator changed it to "Show HN: Adblock Fast – An iOS 9 ad blocker".
Since you do have new things for people to try out, though, it seems like making the title more general is the best solution.
Also, I get that regex is how you do it on iOS9 and it's fast on there because of Apple's specific regex implementation, but you're misleading people that your 7 humongous regex are going to be faster than flagship blockers (uBlock Origin) on the desktop.
The authors of this product should run their adblocker against all of them here: https://www.raymond.cc/blog/10-ad-blocking-extensions-tested...