[Discussion] For A Faster Future

[jspenguin2017]

• jQuery: Changed to lazy load.
• Let and loop: Keeping as-is, no performance difference in my tests.
• a.domCmp: Changed to a more efficient algorithm, it's now faster by about a third.
• a.domInc: Changed to a more efficient algorithm, it's now over two times faster.
• DOM watcher: Keeping, this is very complex, as I can't guarantee a faster logic that I can come up with would do the same, I have to leave this as-is, however, I pulled all RegExp out and pre-compiled them, it should make things slightly faster.
• Minifying: Keeping as-is, minifying gives too little gain, and I would need to have a development version that is not minified.
• Hash function: Changed to MD5, solutions that rely on previous hash function (SHA256) are updated. Even though MD5 is not cryptographically secure, it is good enough for our purpose, I can add a length restriction if someone tries to carry out a collision attack.
• a.cookie() get mode: Changed to a more efficient algorithm.
• Property looping: Changed to a more efficient algorithm.

[jspenguin2017]

Eh... What? http://jsben.ch/#/FKapz ^{ops spelled for wrong, ignore that}

[jspenguin2017]

Looks like V8 is not perfect, but as that can change, I will not make optimization that I think should be done by V8. It is faster now doesn't mean it will be faster later. However, jQuery and the DOM watcher are actual overhead and it's not V8's task to optimize them.

I might also fix let with loop, as the variable is “copied" every iteration and we don't want that.

[jspenguin2017]

let is substantially slower for loops... I think this is a problem on my end, since let does behave differently as per standard, I will fix it.

[jspenguin2017]

Normal usage: After explicit garbage collection:

[DjDiabolik]

I look this discussion... because it's suggested to use Violentmonkey and in the pass it's suggested Tampermonkeys ? What's the differences about this two script manager ? And because this combination it's only suggested to use all things on chrome and not on firefox ?

[jspenguin2017]

@DjDiabolik Violentmonkey is open source. And it is significantly lighter than Tampermonkey.

I will do profile guided optimization for V8 JavaScript engine, but FireFox is using SpiderMonkey. The main reason I only support one browser is that I don't have that much time.

[DjDiabolik]

mmmmmm.... very interesting.... at this point you suggest to use Chrome because you don't have time to test if all it's working also in other browser ?

If yes i can say i currently use all setup on firefox and tampermonkeys and apparently all it's working whitout any issue or critical issue....

If you sugget violentmonkeys... violentmonkeys it's also released for firefox and i thinks i can tryed to disabled tampermonkeys and try to use this for about some days......

[jspenguin2017]

@DjDiabolik What if it doesn't always work? I don't want to fix it.

[DjDiabolik]

Oh... the current version it's work on firefox... this future version i don't know and if not working i thinks i try to found an alternative for firefox.....

EDIT for the moment i can only confirm apparently all it's work on firefox.. and i have the 8.12 script and the filters added on ublock origin....

[jspenguin2017]

@DjDiabolik Here is an alternative that you may want to check out: https://xuhaiyang1234.gitlab.io/AAK-Cont/

[DjDiabolik]

Lol i know this configuration (and i have used AAK on ABP up to about 2 weeks ago)....... i have tryed to setup that but for moment i prefer to use ublock protector ways. How i have already says.. apprently i don't find problems and all it's work whitout any problems :)

The next future.... i don't know :)

EDIT Only for purpose........... also for now... i have removed Tampermonkeys.......... pass to Violentmonkey on Firefox and i have re-add my usual script (Adsbypasser and 8.12 ublock protector).....

[jspenguin2017]

@DjDiabolik I'm not going to stop you from using unsupported setup, but do not open issue before testing on the standard setup.

[DjDiabolik]

But i'm not here for ask support... i'm here only to know because you suggest a single solution and now i know because you can't have time to test all setup whit all different browser and script manager...

I also ever says.... for moment apparently on firefox + violentmonkeys and all currently setup all it's working. and now i know If i have problems whit this setup you can't be helped whit that........

[jspenguin2017]

Extra: A fun challenge for you https://github.com/jspenguin2017/AdBlockChallenge#adblock-challenge

[okiehsch]

https://github.com/jspenguin2017/AdBlockChallenge#ublock-origin-bab-defuserjs-bypassing-nightmare-mode

jspenguin2017.github.io##script:inject(abort-on-property-write.js, Math.floor) :wink:

[jspenguin2017]

@okiehsch Wow, what?! I cached a reference to the good Math...

[okiehsch]

Well, this will obviously never work in real world cases anyway ,because of site breakage, but your rules didn't mention that.

[jspenguin2017]

I explicitly cached the reference to the good Math, somehow BlockAdBlock refuses to use it... Good job on it 👍 I'm not sure if it will cause breakage as I don't think many pages use Math.floor.

[okiehsch]

More than you think, I tried this fix with a few sites to circumvent different anti-adblock scripts, but it always lead to severe site breakage on my end.

[jspenguin2017]

@okiehsch Anyway, it's fixed...


[okiehsch]

Can I use any script:inject that is part of uBO-resources?

[jspenguin2017]

You can use custom ones as well.

[okiehsch]

No need. jspenguin2017.github.io##script:inject(setInterval-defuser.js, (), 1000)

[jspenguin2017]

https://github.com/jspenguin2017/AdBlockChallenge/commit/4c0176b66f3980dfb8fe2d351d7b8fc6dae2b4f0

[okiehsch]

Well, Math.floor and setInterval. were the two obvious ways to circumvent and you clearly only forgot or overlooked setInterval. Now, I don't have a solution. Good job.

[jspenguin2017]

Looks like if we want local i, either way is the same.

[jspenguin2017]

Switching to algorithm 2 😄

[jspenguin2017]

WOW, new a.domInc is over two times faster!

[jspenguin2017]

Not a big improvement, but it's worth it.

[ghost]

these "couple milliseconds faster" microbenchmarks are making me sick

i think you are doing your codebase a big misfavor by making non-obvious (confusing and less readable) and engine-specific (what if they're slower in other browsers?) micro-optimizations instead of going after what's actually slowing it down

inefficient code will be inefficient regardless of the language features used, and different loop styles and caching regexps are exactly the kind of pointless optimizations i hate

javascript should come with an instruction manual that has useful tips like "microbenchmarks aren't representative of real performance" and "simplifying and removing code and just doing less is the best optimization technique"

and something like "think about what the code does, not what the compiler does"

Also, I will be chasing the latest ECMAScript standard that Chrome stable supports

this makes no sense as new features are usually the least optimized ones, unlike older features that have had years of optimization work put towards them and have established coding patterns and conventions to actually optimize for

[jspenguin2017]

@epicgirl1998 If I loop it more, it would be longer, it's not milliseconds, it's percentage. There are many complex code that I cannot remove, and I don't have enough tests to optimize what is actually slowing things down. Also, I don't care if it is slower in other browsers as I don't support them anyway. New features are less optimized but that will change. I won't try to use new features just because it's there though, I will always have a reason to use them, make the code shorter, simpler, or easier to edit later are good examples.

[jspenguin2017]

@epicgirl1998 Also, I am thinking what the code does, it now compares integers instead of strings, which speeds it up significantly. I tested the loop structure because let would create a new variable for each iteration if the variable's reference is kept. But it looks like V8 is able to optimize it. I only tested things I think I am responsible for, I won't try to optimize things that I think it's V8's job to properly compile. And the code is not less readable, as I documented exactly what each function does. If you are just writing rules, all you need to know is what each function do and not how is each function implemented.

[uBlock-user]

these "couple milliseconds faster" microbenchmarks are making me sick

Then don't look at it instead of spewing a temper tantrum like this. Such small optimizations are making the codebase better and simplified with each update. Those milliseconds collectively can make a big difference when you measure the page load time, so nothing is insignificant here.

[jspenguin2017]

Maybe having compilers written in C# was a mistake...

[jspenguin2017]

Overview: Compile: Execution time including Violentmonkey wrapper: Execution time of the Userscript: Execution time of a.make$():

Most of the script execution time is used to load jQuery... I think I should lazy load jQuery...

[jspenguin2017]

Compile time of minified script: change too tiny, and I would need a non-minified version for development, too little gain, and the gain doesn't apply to me, keeping as-is. The execution time is still 49ms, no change there.

[jspenguin2017]

Just realized that jQuery is used in generic solutions... Need to fix that first...

[jspenguin2017]

OK, lazy loading is implemented... Hopefully I didn't break anything while refactoring the code... Here is the commit: https://github.com/jspenguin2017/uBlockProtector/commit/bcaaa3bf1c59f1a87a8952361635c2eacb9c229b

[jspenguin2017]

One test left 😄

[jspenguin2017]

split is significantly slower. Time to optimize the Core.