Privacy
- Wat niemand over je mag weten
Firefox AdBlockplus Geheugen gebruik
19-05-2014, 01:31 door Anoniem, 8 reacties
Firefox AdBlockplus Geheugen gebruik
Inleiding
Recent kwam in het nieuws dat Firefox in combinatie met AdBlockplus een hoge belasting kan hebben voor het werkgeheugen.
"AdBlock Plus verdubbelt geheugengebruik Firefox"
https://www.security.nl/posting/388089/AdBlock+Plus+verdubbelt+geheugengebruik+Firefox
Inmiddels blijkt uit een reactie van het AdBlockplus team dat dat ligt aan de manier waarop Firefox reageert wanneer bepaalde elementen geblokkeerd worden.
Die vaststelling lijkt heel plausibel daar het probleem zich niet (in deze mate?) lijkt voor te doen met andere niet mozilla browser(s) en AdBlockplus.
Ook is het idee inmiddels ontstaan dat het (opnieuw?) onder de loupe nemen van de AdBlockplus rules uit de diverse abonnementen op geheugenbelasting een mogelijkheid is om het soms hoge verbruik naar beneden te brengen.
Dat laatste vroeg ik mij ook af nadat het eerste bericht was verschenen.
Kan het misschien aan het soort abonnement liggen?
Kan het aan de hoeveelheid rules liggen of ligt het juist aan een specifiek aantal en soorten rules?
In een test zoektocht naar een antwoord heb ik geen antwoord kunnen vinden op welke individuele rules uit bepaalde abonnementen specifiek de allergrootste 'klappers' maken als het gaat om het geheugengebruik.
Een aantal specifieke individuele rules werden in de directe about:memory van Firefox wel als "huge" omschreven, het uitschakelen van deze rules zorgde echter niet voor een dramatische verlaging van geheugengebruik op een zeer excessieve testpagina als opgegeven door een mozilla onderzoeker recent. Een testpagina met 428 iFrames.
Wel heb ik meer inzage gekregen in welke abonnementen er zoal zijn (wist het wel een beetje) en wat ze specifiek en op delen kunnen betekenen voor de geheugenbelasting binnen Firefox.
De vergelijkingen lijken hier en daar mogelijk op Appel met Peren vergelijkingen te zijn door de variatie in grootte (het aantal rules) en het specifieke doel van het betreffende filter.
Inhet globale idee achter het vergelijken zaten meerdere gedachten :
* Erachter komen welke rules zorgen voor een hoge belasting in Firefox.
* Kijken hoe een meer acceptabele geheugenbelasting is te bereiken in vergelijking met de resultaten van bijvoorbeeld de Opera browser (versie 20) met AdBlockplus, die geen 'last schijnt te hebben van deze 'geheugen belasting bug' (want geen mozilla browser).
* Kijken hoe toch niet teveel te hoeven in te leveren in aantal rules in vergelijking tot het minimaliseren van de geheugenbelasting.
* Kijken hoe dat uitpakt in de praktijk, worden er voldoende advertenties geblocked; het antwoord daarop zal eenieder voor zich zelf moeten bepalen. Minder regels zal de kans op het doorlaten van advertenties vergroten, wanneer dat het geval is is het dan acceptabel genoeg in verhouding tot de snelheidswinst? Wederom zelf te bepalen.
Wellicht vraag je je af; 'Wat is het nut van een dergelijk onderzoek? Ik heb werkgeheugen zat op mijn pc en nergens last van!'
Met voldoende geheugen capaciteit hoeft een volledig ingeschakelde EasyList in AdBlockplus inderdaad geen probleem te zijn. Doen! (?)
Gewapend met een redelijk snelle processor en ruim voldoende Gb's aan werkgeheugen moesten zowel Firefox en Opera in de test hier toch wel (al dan niet heel even) 'nadenken' bij bezoek aan de googlecode test 'vim'-pagina voordat de betreffende testpagina met 428 iFrames geladen was.
Een pagina met zoveel iFrames is natuurlijk een nogal uitzonderlijk zware situatie die in de praktijk vrijwel niet aan de orde is (?) en waarmee je daarmee ook geen tot veel minder last hebt van het geschetste nieuwshalende 'ophef probleem' (enige efficiëntie nastreven is op zich een goed doel en gewenst).
Anders wordt het wanneer je een device hebt dat met wat minder werkgeheugen capaciteit genoegen moet nemen.
Dat kan bijvoorbeeld een oudere laptop zijn die zich in principe nog prima kan laten lenen voor het lezen van online content. In dat geval kan het een uitkomst zijn als je wel AdBlockplus wil gebruiken maar dat noodzakelijkerwijs goed wil afstemmen op de beschikbare ram.
Lees dan de resultaten met aandacht zou ik zeggen en probeer het eens uit.
Andere goed werkende alternatieven of maatregelen naast AdBlockplus maatregelen kunnen overigens zijn :
* Een firewall met een aangelegde blokkade lijst van een paar honderd belangrijk(st)e advertentie domeinen en of social media domeinen, werkt over het algemeen heel effectief.
* De NoScript addon 'mee laten draaien' met zoveel als mogelijk geen javascripts toestaan, een blacklist van "Untrusted" javascript domeinen aanleggen en bijvoorbeeld standaard iFrames blokkeren.
* Een addon installeren dat het laden van afbeeldingen van 3rd party domeinen monitort : toestaan of blokkeren.
Kijk eens naar Request Policy bijvoorbeeld. Werkwijze wat intensiever, werkt heel goed.
De resultaten zijn een indicatie
Onderstaande uitgesplitste resultaten zijn bedoeld als een grove indicatie, resultaten zijn op 1 systeem getest. Vergelijk desgewenst de diverse uitkomsten met je eigen systeem en bepaal aan de hand daarvan een eventuele wijziging in je filterabonnementen. Meer aanvullende 'omtrent' info onder de 'noot'***.
Browsertests met AdBlockplus rules
Getest op een pagina met 428 iFrames
http://vimcolorschemetest.googlecode.com/svn/html/index-c.html
Selected iframe height (in pixels): (X) 300)
Total: 428 schemes
A) Referentie : Opera Test Mb gebruik algemeen
Hoe doet opera het? Gebruikte versie in de test was versie 20.
(versie 21 heeft m.i. wat vervelende eigenschappen die nog niet zijn opgelost door Opera en gebruik ik daarom niet, dat terzijde)
Geheugenbelasting met Testpage volledig geladen 701,7 mb
Browser opstart 156,9 mb
Globaal aantal regels (simple total paste in een spreadsheet) ± 42673
Maakt globaal een belasting per mb/regel c.q. rule 0,013 mb
Filter : EasyList (de hele reguliere lijst)
(Info uit de lokale Systeem procesmanager : 6 Opera processen uit de systeem procesmanager bij elkaar opgeteld. Firefox gaf deze in één proces weer.)
B) Firefox Test Mb / Gb geheugen gebruik met diverse filters bij bezoek aan de testpagina
Helaas kan ik hier geen tabellen aanmaken, geprobeerd het met deze lay-out aanpak overzichtelijk te houden.
b1) Testpage geladen 2310 mb, Opstart 298,2 mb, Regels ± 42673, mb/regel 0,047 mb
Filter : EasyList (vol regulier)
b2) Testpage geladen 2270 mb, Opstart 300 mb, Regels ± 39954, mb/regel 0,049 mb
Filter : Easylist without rules for adult sites
b3) Testpage geladen 1200 mb, Opstart 288,8 mb, Regels ± 11403, mb/regel 0,080 mb
Filter : Fanboy's Annoyance List
b4) Testpage geladen 1070 mb, Opstart 282,3 mb, Regels ± 6858, mb/regel 0,115 mb
Filter : Fanboy's Social Blocking List
b5) Testpage geladen 852,3 mb, Opstart 277,4 mb, Regels ± 18585, mb/regel 0,031 mb
Filter : Easylist without element hiding rules
b6) Testpage geladen 834,6 mb, Opstart 280,6 mb, Regels ± 1192, mb/regel 0,465 mb
Filter : Easylist Dutch
b7) Testpage geladen 769,3mb, Opstart 280,3 mb, Regels ± 9158, mb/regel 0,053 mb
Filter : EasyPrivacy
Rule met de minste geheugenbelasting, meeste regels, minste mb per regel
b5) Testpage geladen 852,3 mb, Start 277,4 mb, Regels ± 18585, mb/regel 0,031 mb
Filter : Easylist without element hiding rules
[C) De standaard Easy list,
zoals de meeste gebruikers vermoedelijk hebben geïnstalleerd vraagt het meeste aantal Mb's of Gb's bij het laden van deze excessieve iFrame testpagina.
Hoe komt dat en waar ligt dat aan?
Om een antwoord op deze vraag nader te kunnen onderzoeken heb ik de standaard Easylist met deellijsten weer opgesplitst in per aanwezig apart intern deellijst filter, geeft 7 grote filters in totaal.
Vervelend klusje; bijvoorbeeld omdat je in de standaard abonnementslijst geen rules kan deleten.
Andere vervelende bijkomstigheid is dat in de standaard abonnementslijsten je wel individuele rules kan uitschakelen maar geen hele (batch) selecties!
Daarom al deze deellijsten als manual filters moeten aanmaken. Waar import van een heel abonnement filter enkele seconden in beslag neemt is het pasten van grote filter-rules met ettelijke duizenden / tienduizenden regels een aangelegenheid van half-uren / uren alles bij elkaar. Geduld, je moet er van houden.
Easylist opgesplitst in aanwezige deellijsten
c1) Testpage geladen 2270 mb, Opstart 291,2 mb, Regels ± 14077, mb/regel 0,141
Filter : Easylist General element hiding rules
c2) Testpage geladen 977,4 mb, Opstart 278,5 mb, Regels ± 1955, mb/regel 0,357
Filter : Easylist Third-party adverts
c3) Testpage geladen 842,9 mb, Opstart 279,6 mb, Regels ± 3553, mb/regel 0,159
Filter : Easylist Third-party advertisers
c4) Testpage geladen 834,9 mb, Opstart 278,8 mb, Regels ± 6265, mb/regel 0,089
Filter : Easylist General advert blocking filters
c5) Testpage geladen 815,9 mb, Opstart 292,9 mb, Regels ± 10011, mb/regel 0,052
Filter : Easylist Specific element hiding rules
c6) Testpage geladen 813,5 mb, Opstart 280,3 mb, Regels ± 4415, mb/regel 0,121
Filter : Easylist Specific advert blocking filters
c7) Testpage geladen 811 mb, Opstart 278,2 mb, Regels ± 2384, mb/regel 0,223
Filter : Easylist Whitelists
Deellijst met de hoogste geheugenbelasting
c1) Testpage geladen 2270 mb, Opstart 291,2 mb, Regels ± 14077, mb/regel 0,141
Filter : Easylist General element hiding rules
Deellijst met de minste geheugenbelasting, meeste regels, minste mb per regel
c5) Testpage geladen 815,9 mb, Opstart 292,9 mb, Regels ± 10011, mb/regel 0,052
Filter : Easylist Specific element hiding rules
D) Grote geheugen belasting rules
De standaard Easylist is volgens mijn vergelijkingen de grootste geheugen belaster in Firefox met AdBlockplus.
Hoe ziet de geheugenbelasting eruit wanneer van de 7 deellijsten de lijst met de hoogste belasting eruit wordt weggelaten (c1) ?
Easylist filter Minus rule "Easylist General element hiding rules"
d1) Testpage geladen 819,5 mb, Opstart 295,7 mb, Regels ± 28583, mb/regel 0,018
Filter : 6x deel lijst minus Easylist General element hiding rules
E) Overige geheugen tests Firefox en AdBlockplus met deel rules
Benieuwd was ik naar wat de belasting zou zijn wanneer alle op 'iFrame' betrekking hebbende rules zouden worden verwijderd uit de Easylist.
Heb geen nieuwe filterlijst aangelegd met 'iFrame' definities uite de algemene Easylist gefilterd. Dat was veel te omzichtig / kostte vanwege sorteren en langzaam paste proces teveel tijd.
In plaats daarvan een filterlijst aangemaakt van de 739 iFrame rules om te zien wat voor gehuegen belasting dat zou opleveren.
Het resultaat daarvan wijkt niet af van andere minst belastende filterlijsten, waarmee ik omgekeerd aanneem dat het belasting probleem zich niet toespitst op de aanwezige 'iFrame' rules.
Manual iFrame rule list
e1) Testpage geladen 788 mb, Opstart 263,6 mb, Regels 739, mb/regel 0,710
Filter : actieve iFrame rules Easylist 739x
'Geen significant hoger' geheugengebruik met omgekeerd weinig vermoede winst bij het verwijderen van iFrame rules uit de Easylist
Beeldformaat rules ?
Benieuwd was ik naar het effect van de rules met beeldformaat definities (als bijvoorbeeld; ",160x600;" , " -120-600. " , ".120x600." , "/120-600-")
Manual 'afbeelding formaat' rule list
e2) Testpage geladen 817,1 mb, Opstart 278,7 mb, Regels 570, mb/regel 0,945
Filter : Easylist selectie Afbeelding formaten definities
'Geen significant hoger' geheugengebruik en omgekeerd weinig vermoede winst bij het verwijderen van alle afbeelding-rules uit de Easylist.
Dit waren niet alle rules met afbeelding formaat definities, er zijn er vele in combinatie met een omschrijving, deze er eveneen uit filteren was teveel werk, leek uiteindelijk ook niet nodig vanwege het niet erg afwijkende resultaat.
G) Andere nog gunstiger Filter rule combinaties mogelijk?
Ja!
Denk het wel. Kijk maar.
Geactiveerde test combi :
- EasyPrivacy = 9158 regels
- Easylist Dutch = 1192 regels
+ deellijsten Easylist (6x, minus 1x) :
- Easylist Third-party adverts = 1955 regels
- Easylist Third-party advertisers = 3553 regels
- Easylist General advert blocking filters = 6265 regels
- Easylist Specific element hiding rules = 10011 regels
- Easylist Specific advert blocking filters = 4415 regels
- Easylist Whitelists = 2384 regels
Totaal combi samen : ± 38933 regels
Resultaat bezoek test page
Testpage geladen 856,2 mb, Opstart 281,6 mb, Regels ± 38933, mb/regel 0,015
Filters : EasyPrivacy, Easylist Dutch, 6xsubfilter; Easylist Third-party adverts, Easylist Third-party advertisers, Easylist General advert blocking filters, Easylist Specific element hiding rules, Easylist Specific advert blocking filters, Easylist Whitelists
Deze combi geeft (snel) overzien met een browsing testje over diverse krantensites, en ook security.nl nagenoeg tot geen advertenties tijdens het browsen (niet zo snel opgevallen of als zodanig als externe advertentie herkend in ieder geval)
In bovenstaande constatering zit nog een eventuele behoorlijke armslag in, dat je echt zelf zal moeten beoordelen.
Eén en ander hangt namelijk sterk af van welke addons je nog meer hebt geïnstalleerd en de voorkeuren die je daar in hebt aangegeven. Daarnaast is het mogelijk dat je al een firewall filter hebt met de nodige anti-advertentie rules
(Tip; mooie site die "Your Online Choices".
My Own Offline Choice alternatives ? : geen voorkeuren aangeven op betreffende site maar wel alle bedrijven links op die pagina's (page style "no style en dan copy paste naar een tekstverwerker), met hier en daar wat aanpassingen, opnemen in je firewall block lijst is ook al heel effectief!
Twee vliegen in één klap: online privacy dubbel bewaard en een extra blokkade lijst. ;-).
Tot slot,
Veel plezier / succes met zelf je ideale AdBlockplus lijsten / combi samenstellen.
En eventueel met het testen hoe je eigen individuele 'offline' firewall choices online uitpakken.
Verder; reageren hoeft niet, mag wel.
Het stuk met deze verzamelde test resultaten is bedoeld voor het inzicht ; doe er je voordeel mee!
Aanvullingen / opmerkingen / correcties / tips natuurlijk welkom.
Mvg
Noot
*** Let wel :
- foutjes maakt iedereen, ik misschien ook wel, voorbehouden ondanks dubbelchecks
- getallen zijn een momentopname, wel heb ik steeds geprobeerd te wachten totdat het opgegeven verbruik meer stabiliseerde in de opgave
- na elke test, verandering van de filter voorkeuren heb ik steeds de browser tussentijds in safe modus opgestart in de hoop dat mogelijke voorkeur restjes in de cache geschoond werden met als resultaat een redelijk cleane opstart geheugenbelasting
- Aantal genoemde regels per filtersoort; yep, ik weet dat die niet exact kloppen, teveel moeite om voor elk filter naar al die overal zwervende paar extra omschrijvingsregels te zoeken en te verwijderen. Simpele totale paste voor alle filters gedaan in een spreadsheet, daadwerkelijk aantal rules in de filters ligt dus iets lager kleine tientallen?
De indicatie voor de grootte van de diverse filterlijsten blijft goed overeind en dat was het doel.
Inleiding
Recent kwam in het nieuws dat Firefox in combinatie met AdBlockplus een hoge belasting kan hebben voor het werkgeheugen.
"AdBlock Plus verdubbelt geheugengebruik Firefox"
https://www.security.nl/posting/388089/AdBlock+Plus+verdubbelt+geheugengebruik+Firefox
Inmiddels blijkt uit een reactie van het AdBlockplus team dat dat ligt aan de manier waarop Firefox reageert wanneer bepaalde elementen geblokkeerd worden.
Die vaststelling lijkt heel plausibel daar het probleem zich niet (in deze mate?) lijkt voor te doen met andere niet mozilla browser(s) en AdBlockplus.
Ook is het idee inmiddels ontstaan dat het (opnieuw?) onder de loupe nemen van de AdBlockplus rules uit de diverse abonnementen op geheugenbelasting een mogelijkheid is om het soms hoge verbruik naar beneden te brengen.
Dat laatste vroeg ik mij ook af nadat het eerste bericht was verschenen.
Kan het misschien aan het soort abonnement liggen?
Kan het aan de hoeveelheid rules liggen of ligt het juist aan een specifiek aantal en soorten rules?
In een test zoektocht naar een antwoord heb ik geen antwoord kunnen vinden op welke individuele rules uit bepaalde abonnementen specifiek de allergrootste 'klappers' maken als het gaat om het geheugengebruik.
Een aantal specifieke individuele rules werden in de directe about:memory van Firefox wel als "huge" omschreven, het uitschakelen van deze rules zorgde echter niet voor een dramatische verlaging van geheugengebruik op een zeer excessieve testpagina als opgegeven door een mozilla onderzoeker recent. Een testpagina met 428 iFrames.
Wel heb ik meer inzage gekregen in welke abonnementen er zoal zijn (wist het wel een beetje) en wat ze specifiek en op delen kunnen betekenen voor de geheugenbelasting binnen Firefox.
De vergelijkingen lijken hier en daar mogelijk op Appel met Peren vergelijkingen te zijn door de variatie in grootte (het aantal rules) en het specifieke doel van het betreffende filter.
Inhet globale idee achter het vergelijken zaten meerdere gedachten :
* Erachter komen welke rules zorgen voor een hoge belasting in Firefox.
* Kijken hoe een meer acceptabele geheugenbelasting is te bereiken in vergelijking met de resultaten van bijvoorbeeld de Opera browser (versie 20) met AdBlockplus, die geen 'last schijnt te hebben van deze 'geheugen belasting bug' (want geen mozilla browser).
* Kijken hoe toch niet teveel te hoeven in te leveren in aantal rules in vergelijking tot het minimaliseren van de geheugenbelasting.
* Kijken hoe dat uitpakt in de praktijk, worden er voldoende advertenties geblocked; het antwoord daarop zal eenieder voor zich zelf moeten bepalen. Minder regels zal de kans op het doorlaten van advertenties vergroten, wanneer dat het geval is is het dan acceptabel genoeg in verhouding tot de snelheidswinst? Wederom zelf te bepalen.
Wellicht vraag je je af; 'Wat is het nut van een dergelijk onderzoek? Ik heb werkgeheugen zat op mijn pc en nergens last van!'
Met voldoende geheugen capaciteit hoeft een volledig ingeschakelde EasyList in AdBlockplus inderdaad geen probleem te zijn. Doen! (?)
Gewapend met een redelijk snelle processor en ruim voldoende Gb's aan werkgeheugen moesten zowel Firefox en Opera in de test hier toch wel (al dan niet heel even) 'nadenken' bij bezoek aan de googlecode test 'vim'-pagina voordat de betreffende testpagina met 428 iFrames geladen was.
Een pagina met zoveel iFrames is natuurlijk een nogal uitzonderlijk zware situatie die in de praktijk vrijwel niet aan de orde is (?) en waarmee je daarmee ook geen tot veel minder last hebt van het geschetste nieuwshalende 'ophef probleem' (enige efficiëntie nastreven is op zich een goed doel en gewenst).
Anders wordt het wanneer je een device hebt dat met wat minder werkgeheugen capaciteit genoegen moet nemen.
Dat kan bijvoorbeeld een oudere laptop zijn die zich in principe nog prima kan laten lenen voor het lezen van online content. In dat geval kan het een uitkomst zijn als je wel AdBlockplus wil gebruiken maar dat noodzakelijkerwijs goed wil afstemmen op de beschikbare ram.
Lees dan de resultaten met aandacht zou ik zeggen en probeer het eens uit.
Andere goed werkende alternatieven of maatregelen naast AdBlockplus maatregelen kunnen overigens zijn :
* Een firewall met een aangelegde blokkade lijst van een paar honderd belangrijk(st)e advertentie domeinen en of social media domeinen, werkt over het algemeen heel effectief.
* De NoScript addon 'mee laten draaien' met zoveel als mogelijk geen javascripts toestaan, een blacklist van "Untrusted" javascript domeinen aanleggen en bijvoorbeeld standaard iFrames blokkeren.
* Een addon installeren dat het laden van afbeeldingen van 3rd party domeinen monitort : toestaan of blokkeren.
Kijk eens naar Request Policy bijvoorbeeld. Werkwijze wat intensiever, werkt heel goed.
De resultaten zijn een indicatie
Onderstaande uitgesplitste resultaten zijn bedoeld als een grove indicatie, resultaten zijn op 1 systeem getest. Vergelijk desgewenst de diverse uitkomsten met je eigen systeem en bepaal aan de hand daarvan een eventuele wijziging in je filterabonnementen. Meer aanvullende 'omtrent' info onder de 'noot'***.
Browsertests met AdBlockplus rules
Getest op een pagina met 428 iFrames
http://vimcolorschemetest.googlecode.com/svn/html/index-c.html
Selected iframe height (in pixels): (X) 300)
Total: 428 schemes
A) Referentie : Opera Test Mb gebruik algemeen
Hoe doet opera het? Gebruikte versie in de test was versie 20.
(versie 21 heeft m.i. wat vervelende eigenschappen die nog niet zijn opgelost door Opera en gebruik ik daarom niet, dat terzijde)
Geheugenbelasting met Testpage volledig geladen 701,7 mb
Browser opstart 156,9 mb
Globaal aantal regels (simple total paste in een spreadsheet) ± 42673
Maakt globaal een belasting per mb/regel c.q. rule 0,013 mb
Filter : EasyList (de hele reguliere lijst)
(Info uit de lokale Systeem procesmanager : 6 Opera processen uit de systeem procesmanager bij elkaar opgeteld. Firefox gaf deze in één proces weer.)
B) Firefox Test Mb / Gb geheugen gebruik met diverse filters bij bezoek aan de testpagina
Helaas kan ik hier geen tabellen aanmaken, geprobeerd het met deze lay-out aanpak overzichtelijk te houden.
b1) Testpage geladen 2310 mb, Opstart 298,2 mb, Regels ± 42673, mb/regel 0,047 mb
Filter : EasyList (vol regulier)
b2) Testpage geladen 2270 mb, Opstart 300 mb, Regels ± 39954, mb/regel 0,049 mb
Filter : Easylist without rules for adult sites
b3) Testpage geladen 1200 mb, Opstart 288,8 mb, Regels ± 11403, mb/regel 0,080 mb
Filter : Fanboy's Annoyance List
b4) Testpage geladen 1070 mb, Opstart 282,3 mb, Regels ± 6858, mb/regel 0,115 mb
Filter : Fanboy's Social Blocking List
b5) Testpage geladen 852,3 mb, Opstart 277,4 mb, Regels ± 18585, mb/regel 0,031 mb
Filter : Easylist without element hiding rules
b6) Testpage geladen 834,6 mb, Opstart 280,6 mb, Regels ± 1192, mb/regel 0,465 mb
Filter : Easylist Dutch
b7) Testpage geladen 769,3mb, Opstart 280,3 mb, Regels ± 9158, mb/regel 0,053 mb
Filter : EasyPrivacy
Rule met de minste geheugenbelasting, meeste regels, minste mb per regel
b5) Testpage geladen 852,3 mb, Start 277,4 mb, Regels ± 18585, mb/regel 0,031 mb
Filter : Easylist without element hiding rules
[C) De standaard Easy list,
zoals de meeste gebruikers vermoedelijk hebben geïnstalleerd vraagt het meeste aantal Mb's of Gb's bij het laden van deze excessieve iFrame testpagina.
Hoe komt dat en waar ligt dat aan?
Om een antwoord op deze vraag nader te kunnen onderzoeken heb ik de standaard Easylist met deellijsten weer opgesplitst in per aanwezig apart intern deellijst filter, geeft 7 grote filters in totaal.
Vervelend klusje; bijvoorbeeld omdat je in de standaard abonnementslijst geen rules kan deleten.
Andere vervelende bijkomstigheid is dat in de standaard abonnementslijsten je wel individuele rules kan uitschakelen maar geen hele (batch) selecties!
Daarom al deze deellijsten als manual filters moeten aanmaken. Waar import van een heel abonnement filter enkele seconden in beslag neemt is het pasten van grote filter-rules met ettelijke duizenden / tienduizenden regels een aangelegenheid van half-uren / uren alles bij elkaar. Geduld, je moet er van houden.
Easylist opgesplitst in aanwezige deellijsten
c1) Testpage geladen 2270 mb, Opstart 291,2 mb, Regels ± 14077, mb/regel 0,141
Filter : Easylist General element hiding rules
c2) Testpage geladen 977,4 mb, Opstart 278,5 mb, Regels ± 1955, mb/regel 0,357
Filter : Easylist Third-party adverts
c3) Testpage geladen 842,9 mb, Opstart 279,6 mb, Regels ± 3553, mb/regel 0,159
Filter : Easylist Third-party advertisers
c4) Testpage geladen 834,9 mb, Opstart 278,8 mb, Regels ± 6265, mb/regel 0,089
Filter : Easylist General advert blocking filters
c5) Testpage geladen 815,9 mb, Opstart 292,9 mb, Regels ± 10011, mb/regel 0,052
Filter : Easylist Specific element hiding rules
c6) Testpage geladen 813,5 mb, Opstart 280,3 mb, Regels ± 4415, mb/regel 0,121
Filter : Easylist Specific advert blocking filters
c7) Testpage geladen 811 mb, Opstart 278,2 mb, Regels ± 2384, mb/regel 0,223
Filter : Easylist Whitelists
Deellijst met de hoogste geheugenbelasting
c1) Testpage geladen 2270 mb, Opstart 291,2 mb, Regels ± 14077, mb/regel 0,141
Filter : Easylist General element hiding rules
Deellijst met de minste geheugenbelasting, meeste regels, minste mb per regel
c5) Testpage geladen 815,9 mb, Opstart 292,9 mb, Regels ± 10011, mb/regel 0,052
Filter : Easylist Specific element hiding rules
D) Grote geheugen belasting rules
De standaard Easylist is volgens mijn vergelijkingen de grootste geheugen belaster in Firefox met AdBlockplus.
Hoe ziet de geheugenbelasting eruit wanneer van de 7 deellijsten de lijst met de hoogste belasting eruit wordt weggelaten (c1) ?
Easylist filter Minus rule "Easylist General element hiding rules"
d1) Testpage geladen 819,5 mb, Opstart 295,7 mb, Regels ± 28583, mb/regel 0,018
Filter : 6x deel lijst minus Easylist General element hiding rules
E) Overige geheugen tests Firefox en AdBlockplus met deel rules
Benieuwd was ik naar wat de belasting zou zijn wanneer alle op 'iFrame' betrekking hebbende rules zouden worden verwijderd uit de Easylist.
Heb geen nieuwe filterlijst aangelegd met 'iFrame' definities uite de algemene Easylist gefilterd. Dat was veel te omzichtig / kostte vanwege sorteren en langzaam paste proces teveel tijd.
In plaats daarvan een filterlijst aangemaakt van de 739 iFrame rules om te zien wat voor gehuegen belasting dat zou opleveren.
Het resultaat daarvan wijkt niet af van andere minst belastende filterlijsten, waarmee ik omgekeerd aanneem dat het belasting probleem zich niet toespitst op de aanwezige 'iFrame' rules.
Manual iFrame rule list
e1) Testpage geladen 788 mb, Opstart 263,6 mb, Regels 739, mb/regel 0,710
Filter : actieve iFrame rules Easylist 739x
'Geen significant hoger' geheugengebruik met omgekeerd weinig vermoede winst bij het verwijderen van iFrame rules uit de Easylist
Beeldformaat rules ?
Benieuwd was ik naar het effect van de rules met beeldformaat definities (als bijvoorbeeld; ",160x600;" , " -120-600. " , ".120x600." , "/120-600-")
Manual 'afbeelding formaat' rule list
e2) Testpage geladen 817,1 mb, Opstart 278,7 mb, Regels 570, mb/regel 0,945
Filter : Easylist selectie Afbeelding formaten definities
'Geen significant hoger' geheugengebruik en omgekeerd weinig vermoede winst bij het verwijderen van alle afbeelding-rules uit de Easylist.
Dit waren niet alle rules met afbeelding formaat definities, er zijn er vele in combinatie met een omschrijving, deze er eveneen uit filteren was teveel werk, leek uiteindelijk ook niet nodig vanwege het niet erg afwijkende resultaat.
G) Andere nog gunstiger Filter rule combinaties mogelijk?
Ja!
Denk het wel. Kijk maar.
Geactiveerde test combi :
- EasyPrivacy = 9158 regels
- Easylist Dutch = 1192 regels
+ deellijsten Easylist (6x, minus 1x) :
- Easylist Third-party adverts = 1955 regels
- Easylist Third-party advertisers = 3553 regels
- Easylist General advert blocking filters = 6265 regels
- Easylist Specific element hiding rules = 10011 regels
- Easylist Specific advert blocking filters = 4415 regels
- Easylist Whitelists = 2384 regels
Totaal combi samen : ± 38933 regels
Resultaat bezoek test page
Testpage geladen 856,2 mb, Opstart 281,6 mb, Regels ± 38933, mb/regel 0,015
Filters : EasyPrivacy, Easylist Dutch, 6xsubfilter; Easylist Third-party adverts, Easylist Third-party advertisers, Easylist General advert blocking filters, Easylist Specific element hiding rules, Easylist Specific advert blocking filters, Easylist Whitelists
Deze combi geeft (snel) overzien met een browsing testje over diverse krantensites, en ook security.nl nagenoeg tot geen advertenties tijdens het browsen (niet zo snel opgevallen of als zodanig als externe advertentie herkend in ieder geval)
In bovenstaande constatering zit nog een eventuele behoorlijke armslag in, dat je echt zelf zal moeten beoordelen.
Eén en ander hangt namelijk sterk af van welke addons je nog meer hebt geïnstalleerd en de voorkeuren die je daar in hebt aangegeven. Daarnaast is het mogelijk dat je al een firewall filter hebt met de nodige anti-advertentie rules
(Tip; mooie site die "Your Online Choices".
My Own Offline Choice alternatives ? : geen voorkeuren aangeven op betreffende site maar wel alle bedrijven links op die pagina's (page style "no style en dan copy paste naar een tekstverwerker), met hier en daar wat aanpassingen, opnemen in je firewall block lijst is ook al heel effectief!
Twee vliegen in één klap: online privacy dubbel bewaard en een extra blokkade lijst. ;-).
Tot slot,
Veel plezier / succes met zelf je ideale AdBlockplus lijsten / combi samenstellen.
En eventueel met het testen hoe je eigen individuele 'offline' firewall choices online uitpakken.
Verder; reageren hoeft niet, mag wel.
Het stuk met deze verzamelde test resultaten is bedoeld voor het inzicht ; doe er je voordeel mee!
Aanvullingen / opmerkingen / correcties / tips natuurlijk welkom.
Mvg
Noot
*** Let wel :
- foutjes maakt iedereen, ik misschien ook wel, voorbehouden ondanks dubbelchecks
- getallen zijn een momentopname, wel heb ik steeds geprobeerd te wachten totdat het opgegeven verbruik meer stabiliseerde in de opgave
- na elke test, verandering van de filter voorkeuren heb ik steeds de browser tussentijds in safe modus opgestart in de hoop dat mogelijke voorkeur restjes in de cache geschoond werden met als resultaat een redelijk cleane opstart geheugenbelasting
- Aantal genoemde regels per filtersoort; yep, ik weet dat die niet exact kloppen, teveel moeite om voor elk filter naar al die overal zwervende paar extra omschrijvingsregels te zoeken en te verwijderen. Simpele totale paste voor alle filters gedaan in een spreadsheet, daadwerkelijk aantal rules in de filters ligt dus iets lager kleine tientallen?
De indicatie voor de grootte van de diverse filterlijsten blijft goed overeind en dat was het doel.
Reacties (8)
Bedankt voor alle moeite en ja ik ben blij dat nu duidelijk wordt waarom FF zoveel geheugen gebruikt.
AdAway op Android werkt volgens mij ook door IP-adressen uit te sluiten van advertentie domeinen.
Weet iemand een progje dat hetzelfde voor Win32 doet?
AdAway op Android werkt volgens mij ook door IP-adressen uit te sluiten van advertentie domeinen.
Weet iemand een progje dat hetzelfde voor Win32 doet?
Super posting dit en zeer interessant!!! +1
Misschien als je het leuk vindt kun je het ook voor andere add-ons doen (als je die tenminste draait).
Keep it coming :)
Oja, waarom gebruik je trouwens adblocker en niet Ghostery en/of noscript. Daarmee bereik je toch eigenlijk precies hetzelfde...
Misschien als je het leuk vindt kun je het ook voor andere add-ons doen (als je die tenminste draait).
Keep it coming :)
Oja, waarom gebruik je trouwens adblocker en niet Ghostery en/of noscript. Daarmee bereik je toch eigenlijk precies hetzelfde...
19-05-2014, 22:10 door
Willieworteltjes
Gevonden http://winhelp2002.mvps.org/hosts.htm
20-05-2014, 00:24 door
[Account Verwijderd]
-
Bijgewerkt: 20-05-2014, 20:53
[Verwijderd]
Door Miriam4711: Vind het een beetje overdreven over Adblock geheugengebruik, de meeste mensen hebben meer dan nodig aan RAM.
Ik en velen met mij hadden een veel groter probleem, qua absurd hoog geheugengebruik van pc of laptop resultaat vastlopers.
Komt bij door wat Adblock tegen houdt, is er zo wie zo winst qua totaal ram geheugen gebruik, door alle niet geladen ads.
Dit is namelijk de plugincontainer.exe als je streams en chats e.d. volgt, in taakbeheer is dat goed te zien.
Ander topic al gereageerd en werkt prima, loopt nog vast maar veel minder vaak, ideaal voor de oude apparatuur een goede ram optimizer van firefox, in een paar klikken.
Simpele oplossing ik gebruik op mijn oude reserve pc, met maar 2 gig ram en Windows7 Ultimate OS de extensie Memoryfox.
Heeft 2 instellingen of alleen de browser (groen) optimaliseren, dan blijft het geheugen van de plugincontainer als nog hoog.
Of alle ram laten optimaliseren (geel) en het totale geheugen gebruik gaat omlaag, zelf jaren lang gebruikt.
Ik en velen met mij hadden een veel groter probleem, qua absurd hoog geheugengebruik van pc of laptop resultaat vastlopers.
Komt bij door wat Adblock tegen houdt, is er zo wie zo winst qua totaal ram geheugen gebruik, door alle niet geladen ads.
Dit is namelijk de plugincontainer.exe als je streams en chats e.d. volgt, in taakbeheer is dat goed te zien.
Ander topic al gereageerd en werkt prima, loopt nog vast maar veel minder vaak, ideaal voor de oude apparatuur een goede ram optimizer van firefox, in een paar klikken.
Simpele oplossing ik gebruik op mijn oude reserve pc, met maar 2 gig ram en Windows7 Ultimate OS de extensie Memoryfox.
Heeft 2 instellingen of alleen de browser (groen) optimaliseren, dan blijft het geheugen van de plugincontainer als nog hoog.
Of alle ram laten optimaliseren (geel) en het totale geheugen gebruik gaat omlaag, zelf jaren lang gebruikt.
Sorry, maar ik begrijp niet veel van je reactie, behalve dat je de extensie Memoryfox gebruikt in firefox...
Ik meen te kunnen stellen dat al die add-ons/extensies/plugins de browser en daarmee ook de hele pc onveilig maken.Vaak veroorzaken deze plugins vastlopen vd browser en soms zelfs vd hele pc. Ik zie dan ook meer in een adblocker die opgenomen is in de internetsecurity suite (bijv.kaspersky heeft het wel),anderzijds zijn er ook security produkten die het niet bieden of niet meer bieden (bijv.norton 360).Ik zou graag zien dat de internetsecurity-suites plugins als adblockplus,https everywhere,enz. overbodig gaan maken omdat zij deze functionaliteit gaan bieden.Het zou niet nodig moeten zijn dat ik allerlei (vaak slecht beveiligde) extensies aan mijn browsers moet gaan hangen die de boel op zn minst vertragen en zelfs verlammen, en mogelijk juist een opening kunnen bieden aan hackers en malware.
26-05-2014, 18:13 door
Guy Fawkes Maskers
geheugenslurpers
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Chief Information Security Officer
Als IT’er groter worden dan jezelf, in je vak en als persoon. Dat kan alleen als je iedere dag wordt uitgedaagd. Hier worden studenten en wetenschappers in staat gesteld het ondenkbare te creëren. Hierbij is de kracht van het IT-landschap succes-bepalend en dus ben jij dat ook.
Ethical hacker
Bezit jij de hacker mindset en specifieke technische kennis binnen het werkveld van security en compliance? Volg jij ontwikkelingen op de voet en weet jij relevante informatie om te zetten in verbeteringen? Probeer jij die nieuwe proof-of-concept code direct uit op je eigen digitale lab? Dan leren wij je graag kennen!
