Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Inactive Support Threads
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Software
General Apps
AdGuard
AdGuard tweaking (Yes, I confess, I did it again, changed adblocking strategy)
Message
<blockquote data-quote="Lenny_Fox" data-source="post: 925679" data-attributes="member: 82776"><p><strong>Follow up post, actual load time testing of removeparam</strong></p><p></p><p>I compared this with the multi-rule version with single rule version. The multi-rule versions were written in exactly the same manner as the queryprune example I found in the uBlock build-in list. Assuming the author of the build-in uBO filter knows how to write efficient rules, the copied multi-rule version should also be efficient.</p><p></p><p>When using uBO's build in logger I could not notice any performance differences (I repoeated the test 5 times)</p><p></p><p>Single ineffecient version removeparam</p><p>[ATTACH=full]253064[/ATTACH]</p><p></p><p>Muti-rule removeparam version following structure and syntax of queryprune rule of uBO build-in filter</p><p>[ATTACH=full]253065[/ATTACH]</p><p></p><p>So using the uBO logger ihe inefficient rule performed the same as the efficient rule. So I decided to use another tool and to give credit to Yuki the multi-rule version was more efficient (4 digit after the decimal break). So a single in efficient line will cost 0.0001 to 0.0002 response time. Which is a lot when uBo easily processes half a million rules in half a second.</p><p></p><p>Lesson learned: we need crafted rule writers in this forum like Yuki <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite109" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p></p><p><span style="font-size: 18px">EDIT this evening I researched what info these parameters contained, so only kept two removeparam's and dumped all others (I am not paranoid, just playing with stuff <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite109" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /> so it is time to lower my level of excitement on the new found feature and only use it when it really increases privacy). A</span></p><p></p><p>! strip google click identifier</p><p>||google.nl/*glcid$removeparam=glid,domain=google.nl</p><p>! strip google search location parameter</p><p>||google.nl/*gs_lcp$removeparam=gs_lcp,domain=google.nl</p><p></p><p>From a performanc epoint of view these rules worked as good (4 digits behind decimal point) or other factors influencing response time had more impact (other network traffic and/or available bandwith) to notice the difference.</p></blockquote><p></p>
[QUOTE="Lenny_Fox, post: 925679, member: 82776"] [B]Follow up post, actual load time testing of removeparam[/B] I compared this with the multi-rule version with single rule version. The multi-rule versions were written in exactly the same manner as the queryprune example I found in the uBlock build-in list. Assuming the author of the build-in uBO filter knows how to write efficient rules, the copied multi-rule version should also be efficient. When using uBO's build in logger I could not notice any performance differences (I repoeated the test 5 times) Single ineffecient version removeparam [ATTACH type="full" alt="1610872687046.png"]253064[/ATTACH] Muti-rule removeparam version following structure and syntax of queryprune rule of uBO build-in filter [ATTACH type="full" alt="1610872765381.png"]253065[/ATTACH] So using the uBO logger ihe inefficient rule performed the same as the efficient rule. So I decided to use another tool and to give credit to Yuki the multi-rule version was more efficient (4 digit after the decimal break). So a single in efficient line will cost 0.0001 to 0.0002 response time. Which is a lot when uBo easily processes half a million rules in half a second. Lesson learned: we need crafted rule writers in this forum like Yuki :) [SIZE=5]EDIT this evening I researched what info these parameters contained, so only kept two removeparam's and dumped all others (I am not paranoid, just playing with stuff :) so it is time to lower my level of excitement on the new found feature and only use it when it really increases privacy). A[/SIZE] ! strip google click identifier ||google.nl/*glcid$removeparam=glid,domain=google.nl ! strip google search location parameter ||google.nl/*gs_lcp$removeparam=gs_lcp,domain=google.nl From a performanc epoint of view these rules worked as good (4 digits behind decimal point) or other factors influencing response time had more impact (other network traffic and/or available bandwith) to notice the difference. [/QUOTE]
Insert quotes…
Verification
Post reply
Top
