Google test functie in Chrome die batterijduur van apparaten kan verlengen

Google test een nieuwe functie in de Canary- en Dev-versies van Chrome die volgens de techgigant de batterijduur van apparaten kan verlengen. De functie heeft invloed op pagina's die op de achtergrond draaien.

De functie 'quick intensive throttling' moet voorkomen dat achtergrondpagina's overmatig veel batterijduur opslokken. Nu is het zo dat pagina's die in Chrome op de achtergrond worden geladen na vijf minuten worden vertraagd. Met de nieuwe functie worden de JavaScript-timers na tien seconden al beperkt.

Google verwacht dat dit de batterijduur van apparaten kan verlengen. De verlenging van de batterijduur zal over het algemeen van toepassing kunnen zijn op het moment dat er meerdere tabbladen tegelijk worden geopend en de pagina sterk afhankelijk is van JavaScript.

Quick intensive throttling is momenteel alleen beschikbaar in de ontwikkelaarsversies van Chrome. Het is niet bekend wanneer de functie beschikbaar wordt in de publieke versie van de browser.

Reacties (98)

[beautjweetj]

Nu nog een functie om het geheugen in te perken, niet normaal hoeveel het gebruikt als je een paar tabbladen open heb staan.

[jozuf]

Eeuwig terugkerende opmerking.
Ongebruikt RAM is verspilling, als er vrije RAM is, is het beter als het gebruikt wordt en vrij gegeven word als er memory pressure is.
Toen ik in J2ME een applicatie ontwikkelde voor MIDP profielen was het vaak een afweging tussen RAM gebruik (wat heel erg beperkt was, 128KB) of sommige zaken opnieuw berekenen (oftewel CPU cycles gebruiken. Waar er ook niet veel van waren per tijdseenheid op dergelijke devices) omdat je geen RAM meer over had.
Dit gaat nog steeds op, het is altijd een afweging, maar ongebruikt RAM is iig een gemiste kans. Zolang het direct vrij gegeven kan worden als er druk is om andere zaken in RAM te laden (wat eigenlijk altijd zo is, zonodig worden zaken weggeswapped).

[Reactie gewijzigd door jozuf op 24 juli 2024 03:56]

[Xander2]

Ongebruikt RAM is verspilling, als er vrije RAM is, is het beter als het gebruikt wordt en vrij gegeven word als er memory pressure is.

Dat geldt voor operating systems, niet voor applicaties.

Als applicatie heb je geen totaaloverzicht en RAM opslurpen is niets anders dan andere applicaties resources ontzeggen, hogere cache-druk en het OS in de weg lopen.

[Saven]

"Als applicatie heb je geen totaaloverzicht en RAM". Is een aanname en een verkeerde, Chromium kan prima inschatten hoeveel RAM het kan gebruiken. Of krijg je dagelijks swapping meldingen/waarschuwingen van Windows? Nee dus

[batjes]

Niet altijd die melding... Wel dat een desktop of laptop "heel erg traag is" en dan zie je (uitzonderingen daargelaten) altijd dat men Chrome gebruikt en het geheugen tegen de 99% zit te hikken.

Chrome kan zelf heel waardeloos inschatten hoe het het beste de beschikbare RAM kan gebruiken. Het enige wat het ziet is "Hé, er is 2GB vrij" en als het denkt dat nodig te hebben, gaat het dat geheugen ook claimen ook.

Dat er dan andere applicaties zijn die ook graag nog wat geheugen willen hebben, pech gehad. Chrome gaat geen geheugen vrijgeven als het dat zelf niet nodig vind, mocht een andere applicatie daar meer behoefte aanhebben.

Wat Chrome bijvoorbeeld niet (of nauwelijks) doet, is geheugen aanmerken als cache. Zodat Windows zelf kan bepalen van "Hè, dat kan ik nu beter elders gebruiken". Het markeert doorgaans al het geheugen als actief gebruikt geheugen.

Nee, Chrome is echt super waardeloos in de omgang met geheugen.

[kiang]

Dat geldt voor operating systems, niet voor applicaties.

Fout: je browser kan makkelijk RAM 'besparen' door alle tabs behalve die die open staat meteen eruit te knikkeren, en de webpagina opnieuw te laden wanneer je erop klikt: dat is een simpele afweging van RAM vs netwerk- en CPU-load. Wanneer je RAM tekort komt zal je browser dit echter wel beginnen doen: als eerste worden ongebruikte tabs met veel geheugengebruik eruit gebonjourd.

Apps doen dus wel degelijk aan RAM management.

[Xander2]

Natuurlijk doen apps aan geheugen beheer, ik zeg alleen dat het concept van ongebruikt RAM is verspilling niet toegepast kan worden op app niveau, omdat dat het concept van virtueel geheugen in de weg loopt.

Een browser of andere virtuele machine mag dan een andere strategie volgen vanwege het gebrek aan inzicht in toekomstig geheugengebruik en om kernel calls te minimaliseren/performance te reguleren, uiteindelijk beperk je het OS omdat dat het stuk software is dat verantwoordelijk is voor verdeling middelen.

[blorf]

Dit begrijp ik niet helemaal. Je laat je programma de RAM gebruiken die het nodig heeft. Wat beweer je? Dat het assignen van een blok gegeugen waar je niks mee doet zinvol is? Elke amateur-programmeur snapt wel het verschil tussen permanente opslag en geheugen. Vertellen dat het beter is om RAM te gebruiken als je dat toch over hebt is niet echt informatief. Wie waren er nog niet zo ver?

[jozuf]

Nee dat zeg ik niet.
Wat ik zeg is dat je soms de keuze maakt iets in het RAM vast te houden wat je berekend hebt maar op het moment niet meer nodig hebt (of bv assets die ingeladen zijn). Mogelijk heb je die later weer nodig, en als het dan nog in RAM zit heb je winst want hoef je dat werk niet nog een keer te doen.
Soms kies je er juist voor het geheugen vrij te geven en als het nodig is opnieuw te berekenen (of in te laden). Dit is een afweging die je maakt en moet je per situatie bekijken. Factoren als hoe duur de berekening is, hoe vaak je verwacht het nog te gaan gebruiken en hoeveel RAM het inneemt spelen bv mee.
Echter geheugen vrij geven puur om minder RAM te gebruiken is niet per definitie slim. Want dat betekend dus mogelijk dat je vaak kiest voor een herberekening of opnieuw inladen.

[Reactie gewijzigd door jozuf op 24 juli 2024 03:56]

[blorf]

Het zou aan je ontwikkelmethode kunnen liggen, maar ik zou mijn eigen werk niet echt vertrouwen als ik ergens een stuk data ga gebruiken dat door omstandigheden nog blijkt te bestaan omdat er nog een array is met rest-data van een bepaalde functie oid. Welke garantie heb je dat dat onder alle omstandigheden zo is? Het pverzicht over de data die je gebruikt en bewerkt kun je niet zo laten vervagen...

[Reactie gewijzigd door blorf op 24 juli 2024 03:56]

[jozuf]

Die garantie heb je natuurlijk niet. Daarom zeg ik ook dat je het per situatie moet beoordelen.
Een texture gaat in de meeste gevallen niet runtime veranderen ofzo, dus dan kan je die afweging maken.
Parsed JS is bv van toepassing op browsers. Als je een interval hebt die elke X tijd iets doet, wil je dan alles opnieuw parsen/evalueren of kan je wellicht delen waarvan je denkt dat het hetzelfde blijft vasthouden zodat je het sneller kan uitvoeren?
Het is erg afhankelijk van de specifieke situatie zoals ik al aangaf.
Ook kan je er alsnog voor kiezen je berekening te dumpen als je detecteert dat de omstandigheden veranderd zijn.

Het is dus niet dat je data nog hebt die door omstandigheden nog bestaan, het is een keuze dat je het niet vrijgeeft. Natuurlijk kan door memory pressure je data alsnog uit het RAM verdwijnen afhankelijk of je managed of unmanaged memory gebruikt en het platform waar je op ontwikkeld.

In het geval van mijn J2ME app moesten we schermen renderen naar afbeeldingen (wegens allerlei beperkingen van dat framework en platform). Dit waren statische pagina's met tekst die scrollbaar waren.
We kozen ervoor om niet enkel de viewport in RAM te houden maar ook delen ervoor en erna zodat scrollen vloeiender werkte bv.
Op dergelijke devices had je niet echt een gpu met framebuffer etc zoals we nu kennen. Denk bv nokia 3310

[Reactie gewijzigd door jozuf op 24 juli 2024 03:56]

[blorf]

Dat lijkt me caching op OS-niveau. Bij zo'n beetje elke *nix gaat een opdracht die bepaalde bronnen aanspreekt bij directe herhaling een stuk sneller.
Maar in een programma moet echt wel duidelijk zijn welke onderdelen waar hun data vandaan halen.

[sjongenelen]

Waar cachen ze dat? Want een SSD is natuurlijk ook gewoon memory?

[blorf]

Dat doet de kernel. Ingelezen blokken data kunnen worden hergebruikt. Als ik in Linux 2x dezelfde find-opdracht geef wordt bij de 2e keer alles wat nog van de vorige keer in het geheugen staat direct beschikbaar gemaakt met minder of geen schijf-activiteit.

[sjongenelen]

Disk dus

[Saven]

Dat stukje hobbyprogrammeren van jou en daar zuinig met je ram omgaan is heel wat anders dan bij het gebruik van een browser. Als je ram over hebt is het prima om die te gebruiken, @jozuf heeft helemaal gelijk. Dat er naar jouw idee veel ram "onnodig" wordt gebruikt heeft te maken met alle tabs die je open hebt staan en de geschiedenis daarvan. Waarom zou je dat niet opslaan als je toch nog 16gb aan ram vrij hebt? Uiteindelijk geeft je dat een betere gebruikservaring omdat tabs bijvoorbeeld niet (deels) opnieuw geladen hoeven te worden, idem als je back/forward navigeert en pagina's instant laden.

Het is niet alsof er allerlei memory leaks inzitten en er verder niemand omkijkt naar efficiënt werken Is gewoon een doordachte keuze.

[PepijnK]

Maar dat Windows aangeeft dat RAM in principe vrij is, wil niet zeggen dat Windows dat niet gebruikt voor Superfetch of andere zaken. Ja dat is niet acuut nodig, maar het verbetert de gebruikservaring wel als zaken niet steeds van de SSD of HDD gehaald hoeven te worden.

Chrome of Firefox kan niet inschatten of het mijn gebruikerservaring beïnvloedt wanneer er applicaties uit de superfetch cache worden gedrukt.
Zeker op een machine met maar 8 of 16GB RAM ga je dat sneller merken.

Op dit moment heb ik op mijn PC 23GB RAM "vrij", maar Windows gebruikt daar 17GB van voor Superfetch cache. En ik merk zeker wel verschil in hoe snel applicaties op starten als mijn PC in deze staat is versus wanneer ik een GAN heb draaien met een 16GB dataset. Die dataset drukt dan heel de Superfetch cache uit het RAM en het opstarten van Waterfox is op dat moment merkbaar trager. De SATA bus gaat het niet winnen van DDR4 RAM.

[blorf]

Het idee "RAM over hebben" slaat nergens op. Het lezen en bescrhijven ervan kost net zo goed tijd als alle andere handelingen van een computer. Dat ga je niet onnodig doen
Dat de Firefox tabs een hoop redundantie kennen en ook met minder RAM zouden kunnen, ongetwijfeld maar er is niemand die beweert dat dat beter is of standaard altijd doet als het kan.. Natuurlijk ga je geen constructie maken om geheugen te besparen terwijl daar helemaal geen noodzaak voor is...

Overigens vermoed ik dat bij het geheugengebruik van die tabs beveiliging een grote rol speelt.De mogeijkheid om bepaalde informatie van elkaar over te nemen betekent een zeker risico.

[Reactie gewijzigd door blorf op 24 juli 2024 03:56]

[supersnathan94]

Het lezen en bescrhijven ervan kost net zo goed tijd als alle andere handelingen van een computer. Dat ga je niet onnodig doen

Nee, maar dingen opnieuw uitrekenen kost altijd meer dan het uit memory lezen. Zelfs voor een simpele rekensom.

Even een voorbeeldje in Java:
int i = randomObject.getSize();
int j = multiplierList.getFirst();
int result = i*j;
return result;

Zowel int i als j nemen geheugenruimte in en het resultaat van de vermenigvuldiging ook. Er wordt namelijk een nieuwe “int” aangemaakt in geheugen om de waarde op te slaan.
Waarom zou je dat dan direct weer weggooien? Mogelijk komt diezelfde vraag een keer weer terug en zolang het object hetzelfde is (zelfde geheugen pointer) en de lijst met multipliers ook niet gewijzigd is, hoef je alleen maar het geheugen adres uit te lezen en niet eerst nog de vermenigvuldiging te doen (en dus weer naar geheugen schrijven).

Werkgeheugen “aan” hebben staan kost energie, maar er is geen verschil in verbruik tussen “leeg” RAM en “vol” RAM. RAM niet volledig gebruiken is dus inefficiënt.

[THETCR]

Even een voorbeeldje in Java:
int i = randomObject.getSize();
int j = multiplierList.getFirst();
int result = i*j;
return result;

Niet een heel handig voorbeeld. Aangezien de garbage collector in JAVA dit gewoon opruimt uit het geheugen.
Dat maakt de allocation ook totaal overbodig. Waardoor het beter is om direct "return randomObject.getSize() * multiplierList.getFirst();" te doen.

[supersnathan94]

Uiteraard is het handiger direct return te doen. Valt nog wat voor te zeggen om de allocatie van I en J wel los te doen voor leesbaarheid, maar in dit geval zou ik daar ook geen moeite in steken.

Het was echter puur een voorbeeld voor hoe bepaalde talen werken. Als je dit in een methode verwerkt en dat naar een final field wegschrijft (omdat het instance “static” is) houd je het wel in geheugen zolang de instantie bestaat, maar dat is wel een hele berg code om hier als voorbeeld neer te zetten vanaf telefoon .

[THETCR]

In dit geval is het niet logisch om de return value weg te schrijven naar een class property.

Dan moet je alsnog gaan evalueren of de operands gewijzigd zijn en een
een arithmetic operator is vele malen sneller.

Ook meerdere evaluaties van de GC wegen niet op tegen de arithemtic operator.

[supersnathan94]

Oke. Neem dit voorbeeld even minder letterlijk alsjeblieft. Dat scheelt je een hoop denkwerk . In dit geval is er NUL komma NUL reden om het niet in een oneliner te stoppen, maar met iets meer logica erachter wordt dat het al gauw wel en is caching op een manier ineens wel viable. Zeker als het vaak wordt aangeroepen en er een berg calls gedaan zouden moeten worden terwijl het niet nodig is om het iedere keer opnieuw in te lezen omdat de data bijvoorbeeld maar 1x per 12 uur wijzigt of een andere reden.

[THETCR]

Er zijn inderdaad gevallen waarin het verstandig wordt om het in je application state te houden.

Maar men moet hier altijd voorzichtig mee omgaan. Te veel state is vragen om problemen.

Dit fenomeen is de reden waardoor we tegenwoordig Rust hebben.

[blorf]

Wat ik zelf wel vaak zie is mensen die op de feiten vooruit denken te kunnen lopen op grond van ervariing of zo. Ik denk ten eerste niks beter te weten. Ik wijs alleen op een inhoudsloze bewering. "RAM over" is flauwekul. Het betekent niks. Verder heb jij geen flauw idee wat, waarmee en waarvoor ik software maak. Daar heb ik me niet over uitgelaten en het is ook totaal niet van belang. Hoezo heb jij daar wat te zoeken?

[YGDRASSIL]

Dit heet gewoon caching en is doodnormaal in developerland. En het werkt idd zo dat als een app geheugen nodig heeft (in windows) windows andere apps die veel hebben kan vragen wat vrij te geven. Als dat chrome geheugen vooral gecachte data is dan is dat dus performancewise slim in gebruik en is het niet echt weg.

[THA_ErAsEr]

Chrome zou bijvoorbeeld al de eerste 3 links op een pagina in zijn geheugen kunnen laden, zodat als jij er op klikt, die er veel sneller op je scherm staat. Zo zullen er nog wel heel veel cases zijn waar die je RAM vol pompt met zaken om mogelijk in de toekomst sneller of beter te werken.

[blorf]

Alvast beginnen met downloaden van links? Kan, maar dat is gewoon extra functionaliteit, toch? In een progamma alles wat aan bod komt voortijdig zo ver mogelijk uitklappen doe je altijd, neem ik aan. Anders krijg je zo'n floppy-effect.
Android overdrijft dit heel erg. Kun je een pincode niet intypen omdat ie nog tig levels geneste functies moet afwerken waarvan ze dachten dat het handig was.

[Reactie gewijzigd door blorf op 24 juli 2024 03:56]

[The Zep Man]

Eeuwig terugkerende opmerking.
Ongebruikt RAM is verspilling, als er vrije RAM is, is het beter als het gebruikt wordt en vrij gegeven word als er memory pressure is.

Totdat er geen RAM vrijgegeven wordt en een systeem gaat swappen.

Toen ik in J2ME een applicatie ontwikkelde voor MIDP profielen was het vaak een afweging tussen RAM gebruik (wat heel erg beperkt was, 128KB) of sommige zaken opnieuw berekenen (oftewel CPU cycles gebruiken. Waar er ook niet veel van waren per tijdseenheid op dergelijke devices) omdat je geen RAM meer over had.

Appels en konijnen. Je had beperkt geheugen, maar niet veel andere zaken die tegelijkertijd draaiden in een afgebakende sandbox. @beautjweetj heeft het duidelijk over een desktop, waarbij je niet kan spreken van volledig afgebakende sandbox. Het is mogelijk om een tekort te hebben aan geheugen, en het is ook mogelijk om geheugen onnodig te verspillen ten nadele van andere processen.

Zolang het direct vrij gegeven kan worden

Daar zit het probleem. Kan dat? En gaat dat zo snel dat dit het draaien van een ander proces niet verstoort?

[Reactie gewijzigd door The Zep Man op 24 juli 2024 03:56]

[jozuf]

Eens dat het uitmaakt wat voor platform het is, of je nou wilt spreken over sandboxen (waar je bv JVM ook onder zou kunnen schalen), desktops, embedded devices etc.
Het blijft echter gewoon staan alleen neemt het andere vormen aan afhankelijk van het platform.
Een ander voorbeeld is dat als je wilt weten hoeveel seconden er in een dag zijn je dit kan berekenen (60x60x24) en opslaan als waarde in het geheugen zonder het expliciet vrij te geven (disposen als hint naar de garbage collector in c# bv, of expliciet op null zetten en equivalenten) ,als constante kan definiëren als hard getal, of elke keer helemaal opnieuw berekenen. Dom voorbeeld ms maar zelfde principe als wat ik aan wil kaarten.

[Reactie gewijzigd door jozuf op 24 juli 2024 03:56]

[supersnathan94]

Ik zou dat inderdaad voor “efficiency sake” als constante definiëren in de vorm:
private static final int SECONDS_IN_DAY = 60*60*24;

Dat wordt dan compiletime 1 keer uitgerekend en vervolgens beschikbaar gesteld in memory. De garbagecollector kan dan prima uitzoeken of het nog nodig is of niet door gewoon codepaths door te gaan.

[jozuf]

Hier doe je wel gelijk aanname dat je een taal gebruikt met GC, en sluit je dus bv C uit.
Je doet ook een aanname over de compiler/parser, maar die gaat denk ik idd bijna altijd wel op.

[supersnathan94]

Ik doe geen aannames, maar geef een voorbeeld van hoe ik het zou doen en waarom. Het gebruikte voorbeeld is dan ook Java en dus ja een GC taal.

[TheVivaldi]

Ongebruikt RAM is verspilling, als er vrije RAM is, is het beter als het gebruikt wordt en vrij gegeven word als er memory pressure is.

Eeuwig terugkerende opmerking. Continu belasten is niet per se beter. Of ben jij 24 uur per dag in de sportschool te vinden om je lichaam te belasten? Of heb je je huis tot de nok toe volgepropt met spullen waardoor je je huis overmatig belast? Zo werkt dat met RAM ook: het is beter voor de algehele prestaties en efficiënter voor het (accu-/stroom)verbruik als er genoeg bewegingsvrijheid blijft.

[ZeroMinded]

Ik heb liever dat mijn OS en applicaties zo veel mogelijk gebruik maken van het geheugen. Lekker snel ipv dat alles opnieuw van disk moet komen.

[beautjweetj]

ook mee eens, maar als ik alleen Tweakers en YouTube heb open staan vind ik 2GB toch best veel..
Was op reactie van @ZeroMinded bedoeld..

[Reactie gewijzigd door beautjweetj op 24 juli 2024 03:56]

[youridv1]

Kijk dan even, zoals hieronder al gezegd, mbv chromes ingebouwde task manager naar het ram verbruik van je extensies. Als ik tweakers open heb en een 4K youtube video, zit ik onder de 600 MB namelijk.

[supersnathan94]

Mja het verschilt heel erg afhankelijk van gebruikte extensies, maar ook vrij geheugen en het type pagina, ik heb soms twitch tabs die meerdere gigabytes aan RAM in beslag nemen doordat ze de volledige chatlog van 12 uur nog in geheugen hebben. Refresh van de pagina maakt het dan weer 200MB oid.

Ik heb overigens wel 64GB dus dan is 2gig meer of minder niet zo’n ramp. Dat is ws ook de reden dat windows het proces lekker door laag groeien als er nog meer dan 50% vrij is.

[lordawesome]

Ik weet niet wat je verder draait, maar 8gb erbij kost 35 euro en 16gb erbij 65 euro. Dat zijn nu niet onoverkomelijke bedragen.

pricewatch: Kingston Fury Beast KF426C16BB/8
pricewatch: Corsair Vengeance LPX CMK16GX4M2B3200C16

[Marve79]

Ik snap dat gezever over RAM ook nooit zo, je hebt het en het wordt gebruikt en dan gaat men klagen dat het gebruikt wordt

[dieAndereGozer]

Toen ik de vorige keer zoiets zij, kreeg ik een regen aan:"Je kan niet in iemand anders portemonnee kijken!!11!!een1"

Gelukkig zijn we over dat stomme argument heen.

[lordawesome]

Het kan zijn dat ze een apple hebben. Dan kunnen ze of niet upgraden of ze moeten inderdaad flink in de portemonnee duiken. Bij de M2 kost 8GB erbij 230 euro en 16GB erbij 460 euro. In plaats van 35 en 65 euro. Een factor 7

Bron: https://www.apple.com/nl/...e-cpu-en-8-core-gpu-256gb

[dieAndereGozer]

Ja, maar dan kies je voor Apple, dan weet je al dat je een 400 % mark up betaald voor dezelfde hardware, dan mag je ook niet zeuren.

[_Pussycat_]

8 GB erbij kost een nieuwe laptop kopen bij Apple, nog een stuk meer dan 230 euro....

[JanW]

En welke add-ons heb je daarbij in gebruik. Als je bovenin met de rechtermuisknop klikt kan je de Chrome task manager openen en zie je welke tab en welke extensie precies veel geheugen vreet.

[Silent7]

heheh laat ik nu net youtube en tweakers open heeb in Chrome, 617mb geheugen in gebruik.

[TheekAzzaBreek]

Op het moment heb ik 35 tabs open, waaronder een paar tweakers en 6 youtubes. 1.3 GB.
Wel met uBlock en PiHole. Misschien dat advertenties zo veel ruimte innemen?

[Martinspire]

Als ik het had wel, helaas worden er nog genoeg devices met 4 of 8gb geheugen verkocht en kun je die dan niet upgraden. Als het dan nog gedeeld moet worden met andere apps, kom je te kort. En het lijkt me sterk dat je echt 2+gb nodig hebt voor een enkele pagina

[dieAndereGozer]

Tracking zooi wss

[phpnuker]

Volledig mee eens.

[moonlander]

dus jij hebt liever geheugen dat 90% van de tijd niks doet?

[firest0rm]

Als dat betekent dat software efficiënter word met resources en het minder belastend is wel ja.
Zou fijn zijn als programma's het zelfde kunnen doen met minder werkgeheugen.

Stroom verbruik is ook een probleem tegenwoordig.

[Reactie gewijzigd door firest0rm op 24 juli 2024 03:56]

[youridv1]

als je minder stroomverbruik wilt, is ram caching juist een goede oplossing. Dat bespaart je het opnieuw laden van veel hergebruikte componenten aan een website

[firest0rm]

Ja of je schrijft je software zodanig dat het überhaupt geen grote data bundels hoeft te cachen.
Heb nu eerder het gevoel dat die truc als excuus gebruikt word om je software lekker lomp te houden.

[youridv1]

Dat probleem mag je dan ook gelijk aankaarten bij web developers. Een browser is slechts een onderlaag voor de website om op te draaien. Chrome heeft dat proces slechts versneld door te cachen.
Maar goed, met al jouw development ervaring weet jij het beter toch?

[Reactie gewijzigd door youridv1 op 24 juli 2024 03:56]

[firest0rm]

Okey, je hoeft geen developers ervaring te hebben om in te zien dat de afgelopen jaren software met de zelfde functionaliteiten alleen maar zwaarder zijn geworden zonder dat er daadwerkelijk betere kwaliteit geleverd word.

Ik geef niet specifiek Webdevelopers de schuld wat dat betreft zijn alle developers in dat opzicht verkeerd bezig.

[Reactie gewijzigd door firest0rm op 24 juli 2024 03:56]

[Verwijderd]

Zeker als je Java en JavaScript gebruikt

[moonlander]

Maar dat is toch met alles zo. Waarom hebben we nu dan niet meer de Pentium II of de 386 net turbo knop. Of een iPad van 10 jaar geleden die toen snel was, nu ook niet snel meer is.

[dog4life]

Wist je dat die turbo knop juist het systeem vertraagde (om zo oude software op de juiste, tragere, snelheid af te spelen?)
Turbo bekt wel lekkerder natuurlijk

[youridv1]

Is dat zo? Jij wil beweren dat het internet niet enorm vooruit gaat? Dat de kwaliteit en resolutie van de paginas die je gebruikt niet enorm is toegenomen? Ik zou de waybackmachine even opstarten om je geheugen op te frissen.

Dat websites niet beter worden qua gebruiksgemak kun je beter bij de opdrachtgever zoeken dan bij de dev. Die 14 ads en 3 autoplaying videos hebben de devs niet bedacht.

Of start word 2003 even op, of ga de boekhouding doen in een oud pakket of ga lekker fotoshoppen in het originele programma. Nee geen vooruitgang

[Reactie gewijzigd door youridv1 op 24 juli 2024 03:56]

[blorf]

Een goed voorbeeld ken ik van firefox. Als je heel snel 10 tabs wil wegklikken merk je duidelijk dat er veel te veel gebeurt. Gevolg is dat er tijdens die 10 clicks een aantal tabs niet luisteren en gewoon blijven staan. Het wordt meer dan 10 clicks...
Daar kunnen de FF-ontwikkelaars een mooi excuus voor verzinnen maar we hebben het over het uit beeld halen van 2d vensters die reeds bekend zijn bij de GUI. Dat hoort geen tijd te kosten. Alle eventueel bijkomende handelingen mogen geen zichtbaar effect hebben op de console/voorgrond.

[Reactie gewijzigd door blorf op 24 juli 2024 03:56]

[blorf]

Finally. Iemand die het snapt. De data die je programma nodig zou kunnen hebben ga je niet ergens achter verstoppen, maar dat wil niet zeggen dat het een goed idee om allerlei willekeurig data maar vast in het geheugen te laden voor het geval dat.
Voordat je begint met coden heb je dit als het goed is op zijn minst grof in beeld.

[Aaargh!]

Zo simpel is het natuurlijk niet. Ten eerste is de browser niet de enige app die draait, en het is voor mij niet ongebruikelijk om 200+ tabs open te hebben dus dat tikt nogal aan als de browser niet efficient met RAM omgaat. Ten tweede kan RAM gebruik verminderen ook zorgen voor performance verbeteringen, ongeacht hoe veel RAM je vrij hebt.

[moonlander]

Het geheugengebruik ligt eerder bij jou dan dat je de schuld neerlegt bij een browser.

[Aaargh!]

Zeker met veel tabs open maakt het uit hoe efficient de browser met geheugen omgaat. Elk beetje inefficiëntie moet je vermenigvuldigen met het aantal open tabs. Op het moment heb ik 326 tabs open en daar heeft Safari geen enkele moeite mee. Ook niet met een heleboel andere apps open (o.a. XCode, Preview met een tiental PDF's, Excel, Mail, Teams, etc.). Heb zelfs nog 12GB RAM vrij (van de 64). Dat hoef je met Chrome niet te proberen.

[moonlander]

Ik begrijp dan niet helemaal wat je dan met 326 tabs moet? Als je het hebt over efficientie qua geheugen, dan vraag ik mij af waar de efficientie van tabs wegkomt als het er zoveel zijn.

[svenM]

Ik heb liever geen bende applicaties op mijn computer die allemaal beslissen dat ze wel dat bij geheugen willen. Chrome, visual studio, teams, ...

[dieAndereGozer]

Klinkt een beetje als het argument die een ICT leraar had toen ik zei dat hij heel erg inefficient met het geheugen om ging:"Iedereen heeft toch 8 GB ram?" Waarop mijn antwoord was:"Das mooi als iedere applicatie zo nadenkt, dan boot je straks windows en dan zit je al op 8 GB, open je kladblok? 8GB, open je een browser? Nog eens 8 GB. Straks heb je 64 GB aan ram nodig om een spotify tab open te hebben naast facebook."
En in plaats van gelijk te geven ging hij uiteraard met zijn statusniveau pronken dat ik het fout had. Logical fallacies 101.

[youridv1]

Komt hij weer hoor. "haha RAM verbruik slecht"
Ondertussen is chrome een snelle browser die intelligent gebruik maakt van caching om zo niet onnodig dingen opnieuw te hoeven inladen vanaf het netwerk of de lokale schijf. Maar ram verbruik slecht, zegt de tweaker in de comments zonder bron, die ogenschijnlijk nul software development ervaring heeft.

Allemaal klagen dat andere browsers traag kunnen zijn en als er dan een browser komt die dat probleem oplost door middel van informatie langer in het geheugen houden voor later hergebruik, dan is dat ineens ook niet goed.

Jij hebt liever dat chrome al zijn ram gelijk weer leeggooit, zodat het de volgende keer dat jij op de back knop drukt in je browser, of teruggaat naar een pagina waar je al bent geweest 2 minuten eerder weer lekker van scratch kan gaan downloaden? Of wil je dat hij het swapt naar je bootdrive, wat ook enorm traag is. In plaats van dat het gewoon gebruikt wordt en DIRECT vrijgegeven wordt wanneer de pc in het nauw komt qua vrij werkgeheugen?

[Reactie gewijzigd door youridv1 op 24 juli 2024 03:56]

[youridv1]

Verwissel chrome in mijn comment met firefox of edge en er verandert niets.

Oh, zijn webpaginas alleen html dan? Ik zou javascript even disablen met een extensie en even rondkijken op het internet

[Reactie gewijzigd door youridv1 op 24 juli 2024 03:56]

[Verwijderd]

En daar zit dus precies het probleem. Te veel zooi.

Te veel trackers te veel zooi op de achtergrond.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 03:56]

[youridv1]

Dan download je toch de open source versie, chromium? Of librewolf

[supersnathan94]

Chrome en edge zijn beiden wel gebaseerd op dezelfde onderliggende code dus dat is niet per se een verschil natuurlijk.

Neemt niet weg dat in op macOS veel meer kan doen met safari dan met chrome zonder dat daar merkbaar traagheid optreed. Safari met 700 tabs is geen enkel probleem op mijn 2015 macbook pro. Chrome daarentegen…die houd met 200 tabs wel op en wordt significant trager bij swap loading.

Er zitten dus wel degelijk verschillen tussen browsers. Nu is safari natuurlijk volledig gebouwd voor het geheugen management van macOS dus daar kan chrome niet aan tippen, maar dan nog is het verschil echt significant.

[TheVivaldi]

Chrome en edge zijn beiden wel gebaseerd op dezelfde onderliggende code dus dat is niet per se een verschil natuurlijk.

O, dus daarom klagen veel mensen dat Vivaldi traag is... Nee, gebouwd op de onderliggende code zegt niet alles.

[dieAndereGozer]

Laat ik nou net overal noscript gebruiken en het minimale aanzetten. Zie je toch dat chrome meer gebruikt dan firefox voor een niet merkbaar verschil.

[Enai]

Dat zou inderdaad beter zijn, want dan zijn er geen interactieve pagina's meer en kun jij dus ook niet meer antwoorden.

[MauvL]

Dat zal tijd worden. Chrome slurpte dagelijks zo enorm aan de accu dat ik 'm vervangen heb door Edge.

[Vortigen]

Scheelt dat erg veel of je weet?
Ik gebruik namelijk ook Chrome op mijn android telefoon.
Als Edge beter is qua accuduu dan ga ik die denk ik gebruiken.

[MauvL]

Ja. Enorm. Ik had eerst nog Firefox geprobeerd, maar die werkte niet goed samen met Lastpass.

[firest0rm]

Firefox werkt prima met LastPass... werk er dagelijks mee.

Maar het zou idd fijn zijn als software efficiënter ontwikkeld word.
Teams is bijvoorbeeld ook al zon enorme werkgeheugen slurper.

[supersnathan94]

Teams was dan ook gebouwd op Electron wat onder water chromium gebruikt als renderengine. Dat verklaart direct een hele hoop. Zeker op het gebied van performance op medium systemen (4-8gb ram): https://tomtalks.blog/mic...ectron-for-edge-webview2/

[Franckey]

Edge heeft een goede ingebouwde password manager (met handige koppeling met de Authenticator app), dan heb je toch geen andere oplossing zoals Lastpass meer nodig?

[supersnathan94]

Als je alleen edge gebruikt niet nee…

Maar dat doet “niemand” en dus moet je andere oplossingen hebben. Ik gebruik zelf iCloud Keychain. En daar is gelukkig een plugin voor edge voor.

[dieAndereGozer]

MAar wie gebruikt er edge

[spokje]

Als Google het continu pingen van je telefoon richting de Google servers nou eens aan banden zou leggen, dat zou pas batterij schelen

[hcQd]

Als NATs niet na een paar minuten inactieve tcp-verbindingen zouden verbreken kan dat pingen en stuk minder frequent.

[dieAndereGozer]

Dus omdat google constant data zit te vergaren is dat de schuld van je NAT? Mooi.

[ddofborg]

Het onnodig gebruik van RAM is wel een probleem. Natuurlijk wil je dat je RAM zoveel mogelijk vol zit als het ook echt nuttig is. Cachen van veel vaak bestanden bijvoorbeeld is nuttig gebruik. Of als je YouTube afspeelt in Chrome dat je grotere buffer hebt voor je 4K video. Hiermee wordt je computer systeem soepeler.

Het omgekeerde klopt echter niet altijd.

Veel RAM gebruiken wil niet zeggen dat dingen soepeler door blijven. Simpel weg omdat als Chrome 90% van je RAM gebruikt, kunnen andere applicaties (en OS) maar 10% gebruiken. Wanneer er meer RAM nodig is, zal het OS een deel van het RAM op de disk opslaan en zo RAM vrij maken. Als dit vaak gebeurt, dan heb je wel een veel minder soepel systeem.

Je muziek speler of editor heeft ook RAM nodig en als deze beiden bijv. 20% nodig hebben, dan moet 10% van de door Chrome gebruikte geheugen naar de disk worden geschreven. Als Chrome dat geheugen weer wil aanspreken, wordt het weer van de disk gelezen. Dan moet weer een ander stuk naar de disk wordt weggeschreven als een andere applicatie weer extra geheugen nodig heeft. En zo heb je dus in eens veel disk operaties nodig die eigenlijk veel beter in het gebeuren waren gebleven.

Veel tabs/windows in Chrome open hebben is gewoon slecht voor de performance van je systeem. Als je bijv. nu 50 pagina's opent in Chrome, zul je er niet veel van merken. Maar zeg na 24 uur (met dezelfde 50 pagina's) zal je systeem trager worden. Terwijl in theorie er niet meer resources voor nodig zijn.

[Ventieldopje]

Mwa, zo simpel is het ook weer niet. Geheugen kan ook "in gebruik" zijn maar wel bestempeld als "vrij als iemand anders het nodig heeft". Programma's kunnen dus ruimte reserveren. Als een programma dus 80% geheugen gebruikt wil dus niet zeggen dat er maar 20% over is om te gebruiken door anderen.

[CopyCatz]

Developer: “ik heb eindelijk de code wat kunnen optimaliseren, scheelt een hoop resources”.

Marketeer: “ah, een feature die de batterijduur van devices kan verlengen!”.

[dasiro]

Inderdaad, dit is gewoon een hoax die niets met de batterijduur te maken heeft, maar met verbruik van hun app.

Moest het écht zo zijn, dan kon je de app om de zoveel tijd laten draaien en zou je batterij langer mee gaan, maar dit is dus niet hetzelfde.

[Silent7]

Ooh mooi, ik pluste je eerder vandaag, had precies hetzelfde idee, mooi te zien dat je reactie nu bovenaan staat.

[rko4u]

Technisch kan het natuurlijk ook niet, het verlengen van de batterijduur door het draaien van een app in een sandbox. Alsof je device met browser minder electriciteit gebruikt dan zonder. Dat kan alleen wanneer je andere apps afsluit of bijvoorbeeld het beeld donkerder maakt.
Het is in dit geval een mindere verkorting.

[YopY]

Het is alleen - voor zover ik op kan maken uit dit artikel - geen nieuwe code of optimalisatie, maar een setting die van 5 minuten naar 10 seconden gezet is.

[mutley69]

Eigenlijk schrijft Google hier dat de oudere versies van Chrome dus slecht geschreven zijn. Mag ik het zo hard en strak formuleren?

[YopY]

Nou nee, ze hebben alleen een andere instelling voor wanneer achtergrondtabs langzamer gaan draaien.