Ublock: [Request] update the blockers' efficiency comparison on Wiki page
Recently, Firefox 41 was released, which improves Adblock Plus performance.
Could you make the updated comparison of uBlock Origin and other blockers on your Wiki page?
The comparison would be made the same way it has been done here in the past.
But it would be done for the latest stable versions of Firefox and Chrome with the latest stable versions of blockers (by which uBlock would be replaced by uBlock Origin).
Of course it is expected that uBlock Origin will still have the best scores. However it would be nice to see the updated data on current browsers.
gituporabnik
All 7 comments
Not worth to update that page because all the data was obtained using Chromium. The Firefox fix does not affect Adblock Plus' efficiency for Chromium. I did update the wiki page specific to Firefox though: https://github.com/gorhill/uBlock/wiki/Firefox-version:-benchmarking-memory-footprint, and the graphes on the front page of the project.
gorhill
on 25 Sep 2015
Sorry, I didn't know it has been already updated. Thank you!
gituporabnik
on 25 Sep 2015
The latest comparisons were done a year ago and since then all software in question have further evolved. As a result the performance comparisons are no longer valid between current solutions.
Would you mind to update the performance comparison soon?
alexara
on 30 Aug 2016
I agree @alexara , watched The Joy of Coding today, and there were a few uBo mentions about performance degradation lately (in FF nightly), nothing confirmed but worth mentioning just in case.
Betsy25
on 25 Nov 2016
Anybody can do performance benchmarks -- it does not have to be me. I am not aware of any performance degradation for uBO itself, so whoever claims this will have to back it up with actual data. Example of such data was provided in release notes of 1.9.0, 1.9.8 and 1.9.12 recently for example.
gorhill
on 25 Nov 2016
Its about tab switching performance (spinner) - not page loading.
27:00, 40:00 - 50:00.
gwarser
on 25 Nov 2016
Look carefully at the text in his screen, this is what it shows:
| extension | before | after | diff |
|---|--:|--:|--:|
| total_time | 5,010,524,050 | 7,161,356,511 | +2,150,832,461 |
| browser-child.js | 3,792,426,362 | 4,298,098,825 | +505,672,463 |
| PBrowser::Msg_LoadURL | 1,054,571,964 | 2,092,041,467 | +1,037,469,503 |
| greasemonkey | 96,365,567 | 305,125,460 | +208,759,893 |
| uBlock0 | 31,593,644 | 376,765,310 | +345,171,666 |
| acewebextension | 19,927,016 | 26,961,886 | +7,034,870 |
| webNavigationContent.js | 9,322,483 | 43,646,957 | +34,324,474 |
| ExtensionContent.jsm | 2,265,083 | 4,855,795 | +2,590,712 |
| vimfx | 65,535 | 2,097,151 | +2,031,616 |
| rpcontinued | 131,071 | 524,287 | +393,216 |
This shows is that _all_ extensions in his list suffered a regression re. PContent::Msg_ReadPermissions, so most likely explanation is that a change in Nightly caused that -- that would be the first place to look at. If uBO appears to be proportionally more sensitive, that does not mean something changed in uBO, it just means uBO might be more sensitive to whatever performance regression was introduced, keeping in mind uBO is an extension which does _a lot_ of work compared to other extensions (kicking in for every single network request being made , etc.)
Since 1.9.0, all network requests except for popup candidates are handled without needing shouldLoad/sendRpcMessage.
gorhill
on 25 Nov 2016
Related issues
ghost
路
3Comments
pfofi
路
4Comments
Darkspirit
路
4Comments
GitHubBlow
路
4Comments
Travisi
路
3Comments
Most helpful comment
Look carefully at the text in his screen, this is what it shows:
| extension | before | after | diff |
|---|--:|--:|--:|
| total_time | 5,010,524,050 | 7,161,356,511 | +2,150,832,461 |
| browser-child.js | 3,792,426,362 | 4,298,098,825 | +505,672,463 |
| PBrowser::Msg_LoadURL | 1,054,571,964 | 2,092,041,467 | +1,037,469,503 |
| greasemonkey | 96,365,567 | 305,125,460 | +208,759,893 |
| uBlock0 | 31,593,644 | 376,765,310 | +345,171,666 |
| acewebextension | 19,927,016 | 26,961,886 | +7,034,870 |
| webNavigationContent.js | 9,322,483 | 43,646,957 | +34,324,474 |
| ExtensionContent.jsm | 2,265,083 | 4,855,795 | +2,590,712 |
| vimfx | 65,535 | 2,097,151 | +2,031,616 |
| rpcontinued | 131,071 | 524,287 | +393,216 |
This shows is that _all_ extensions in his list suffered a regression re.
PContent::Msg_ReadPermissions, so most likely explanation is that a change in Nightly caused that -- that would be the first place to look at. If uBO appears to be proportionally more sensitive, that does not mean something changed in uBO, it just means uBO might be more sensitive to whatever performance regression was introduced, keeping in mind uBO is an extension which does _a lot_ of work compared to other extensions (kicking in for every single network request being made , etc.)Since 1.9.0, all network requests except for popup candidates are handled without needing shouldLoad/sendRpcMessage.