Berekeningen in Google Sheets gaan dubbel zo snel, alleen in Chrome en Edge

Google heeft de snelheid van berekeningen van onder meer conditionele opmaak, formules en draaitabellen verdubbeld, maar dat gebeurt vooralsnog alleen in de eigen browser Chrome en in Microsoft Edge. De verbeteringen volgen later voor andere browsers.

Google Sheets Smart Fill

Google zegt niet wanneer, maar het bedrijf vermeldt dat de hogere snelheid van berekeningen ook naar Apple Safari en Mozilla Firefox zal komen. De hogere snelheid komt door de nieuwe webtechnologie WasmGC en dat staat voor WebAssembly Garbage Collection. Dat is een extensie van WebAssembly die garbage collection mogelijk maakt en daardoor het uitvoeren van code moet versnellen. Chrome ondersteunt WasmGC sinds eind vorig jaar.

Door de berekeningen uit te voeren met WasmGC moeten ze dubbel zo snel gaan en dat gaan gebruikers merken in onder meer formules, conditionele opmaak en draaitabellen, zo zegt het bedrijf. De verbeteringen moeten merkbaar zijn in alle soorten berekeningen, van kleine tot grote en complexe sheets.

Reacties (51)

[MOmax]

Misschien een unintentional first post, maar ik vond dit een informatief achtergrond artikel bij dit nieuws:

https://web.dev/case-studies/google-sheets-wasmgc

Kern van het verhaal is dat JavaScript een stuk langzamer is. Ik miste dat in het artikel als achtergrond waarom Google deze move maakte.

[Edit] @dez11de Dat staat ín dat artikel:

WasmGC is an extension to the existing WebAssembly specification which adds the primitives needed to compile garbage collected languages (such as Java). For example, WasmGC adds instructions for defining types and allocating garbage collected data structures. WasmGC is poised to do for garbage collected languages what Wasm did for C++ (for example, Photoshop or Google Earth), which is to bring them to the web at near native speed. At Google, we believe that WasmGC has the potential to be even more impactful than Wasm because of the popularity of garbage collected languages.

[Reactie gewijzigd door MOmax op 22 juli 2024 15:58]

[HunterPro]

Wie kan me uitleggen waarom een garage collector toevoegen executie sneller kan maken? Dat lijkt me meer een ‘je hoeft niet zelf je geheugen te managen’ dingetje?

[dez11de]

De snelheidsverbetering komt door de overstap van JavaScript naar wasm.

Hier lichten ze het wat meer toe: https://web.dev/case-studies/google-sheets-wasmgc

Waarom het artikel zo loopt te bazelen over de garbage collector is me ook niet duidelijk.

[Reactie gewijzigd door dez11de op 22 juli 2024 15:58]

[R4gnax]

En dat is een snelheidsverbetering die Google ook had kunnen maken door Wasm in te zetten en de code die spreadsheet berekeningen implementeert in bijv. Rust te implementeren. Dat is al te transpileren naar perfect werkende Wasm in alle browsers.

Verder is het helemaal niet zo dat Google deze nieuwe feature later ook expliciet naar andere browsers brengt, maar dat in Safari en Firefox Google's nieuwe code als vanzelf zal gaan werken zodra deze browsers ook de WasmGC extensie gaan ondersteunen. (feature sniffing) Het is helemaal niet zo, zoals de berichtgeving doet vermoeden, dat Google hier nog op goodwill mag rekenen vanwege de bloed, zweet en tranen die ze hypothetisch nog zouden gaan verzetten om dat karwei gedaan te krijgen, uit de goedheid van hun (gitzwarte) hartje.

Wat dit is, is simpelweg een sluippad om Google's eigen diensten weer eens significant beter te laten presteren op hun eigen browser t.o.v. de competitie - wederom door een nog niet uitgewerkte onvolwassen, niet breed ondersteunde standaard die ze zelf verzonnen hebben, te nemen en een implementatie er mee door te forceren die ze ook gewoon met brede ondersteuning hadden kunnen leveren.

Hetzelfde hebben we in het verleden meermalen gezien met Gmail, GDocs, en het meest infameus met YouTube - waar Google heel YouTube liet draaien op een versie van de Web Components specificatie die ze zelf aangedragen hadden maar het nooit tot standaard gehaald had en die enkel in Chrome werd ondersteund, waardoor alle andere browsers stevig wat meer resources moesten verstoken en alles trager werkte en trager inlaadde omdat er een hele stapel extra JavaScript nodig was om die specificatie (nagenoeg) sluitend te emuleren.


Dit is principieel een overtreding van de Digital Markets Act:
Voorkennis van de browser die je als kernplatformdienst uitbrengt gebruiken om een grote andere dienst die je ook uitbrengt bevoorrecht te kunnen behandelen, waardoor jouw kernplatformdienst het beter doet dan die van de concurrent en daarmee (nog meer) marktaandeel naar zich toe kan trekken.
Geef je een browser uit, dan hoor je gewoon het testen van de wateren van dit soort pre-nascente technologie aan andere partijen over te laten in plaats van moedwillig onder het mom van "we moeten wel test-implementaties in de echte wereld hebben," je eigen product te bevoorrechten.

[Reactie gewijzigd door R4gnax op 22 juli 2024 15:58]

[THETCR]

De WebAssembly workgroup bestaat naast Google uit W3C, Mozilla, Apple etc.
De GC ligt daar al meer dan 6 jaar op tafel als voorstel.

Google loopt wel weer op de zaken vooruit, het is immers een proposal waar nog geen definitief besluit over is genomen.
Ze doen dat wel vaker, ook omtrent ECMAScript.

Mocht de proposal wel worden aangenomen dan is het in lijn met de afspraken dat de andere leden het ook implementeren.

Het is inderdaad, weer eens, niet charmant van Google.

[Reactie gewijzigd door THETCR op 22 juli 2024 15:58]

[Horatius]

Ja dit is inderdaad bedacht door de WebAssembly Community Group waar de andere browser makers ook in zitten.

Maar als ik kijk naar de deelnsmers van die groep zet ik toch vraagtekens bij de invloed van Google. Welke 95 deelnemers vanuit Google heeft en ook 2 van de 3 chair posities (positie 3 is een onafhankelijke professor lijkt).

Apple heeft 7 deelnemers, Microsoft 20 en Mozilla 9.

Deelnemers zijn mensen die toegelaten zijn door de chair en een bijdrage hebben geleverd. Bij meetings moet er onder deze personen een consensus worden gecreëerd voor beslissingen.
https://www.w3.org/groups/cg/webassembly/participants/

Heb zelf nergens een reden kunnen vinden om aan te nemen dat Google daar niet vrij sterk met de scepter wil zwaaien als ze willen of in ieder geval sterke invloed kan uitoefenen.

Dus in dit gevalt loopt Google vooruit maar kan zichzelf ook zekerheid bieden dat ze het er wel doorheen krijgen, waar andere browser ontwikkelaars dat misschien veel minder kunnen.

[Reactie gewijzigd door Horatius op 22 juli 2024 15:58]

[uiltje]

Nou ja, aan de andere kant kan je van Google wel zeggen dat ze veel innoveren en dat komt ook vaak ten goede aan de klant. Zeker op het gebied van snellere verbindingen, quantum-computer secure TLS etc. hebben ze behoorlijk aan de weg getimmerd. Het is dus niet zo vreemd dat ze bij de standaardisatie ook een behoorlijke vinger in de pap hebben. Het is echter wel jammer dat ze na 6 jaar nog steeds de tech niet hebben weten te standaardiseren, 6 jaar is best lang, zelfs als het over IT standaardisatie gaat.

[Horatius]

Ik zeg daarom ook niks over of het terecht is of niet. Als developer kijk ik met grote liefde naar Google maar als staatsburger ook met zorgen.

De comment boven mij presenteerde alsof het een gelijke samenwerking is. Daar kan je vragen bij stellen, en als het geen eerlijke samenwerking is kan je je afvragen of het terecht is.

Gevolg is alleen dat als Google daar veel macht heeft dan zit daar flinke belangenverstrengeling wat de concurrenten flink in het nadeel kan stellen.
Hoeveel Google ook bijdraagt maakt dan niet uit en daarom is het belangrijk om kritisch hier naar te blijven kijken.

Mocht de machtsverhouding in die groep flink verschoven zijn hoop ik dat Mozilla en misschien de anderen zich daar sterk over uitspreken. Misschien dat de DMA ze daar in steunt

[Reactie gewijzigd door Horatius op 22 juli 2024 15:58]

[kimborntobewild]

Het is inderdaad, weer is, niet charmant van Google.

Ik weet dat je hier niet mag klagen over spelling, maar dat is zo vreselijk fout dat ik het niet kan laten het toch hier te noemen.

[THETCR]

Dankjewel, gecorrigeerd.

[Spockz]

Blijkbaar is de originele rekenengine geschreven in Java: https://news.ycombinator.com/item?id=40812209

[R4gnax]

En wat had Google gelet die eerst naar bijv. Rust te porten? Of naar C++?
(Of naar C#? Hou er even rekening mee dat MS al een compiler heeft die werkt op bestaande Wasm engines, zonder de WasmGC extensie - omdat de GC in de runtime zit die ze er mee in compileren.)

Overigens- als je het originele artikel leest, zul je er achter komen dat ze niet de oude Java codebase omgezet hebben, maar de nieuwere JavaScript codebase die middels de Java to Closure JavaScript Compiler (J2CL) gegeneerd was.

De eerste zin die de hint geeft:

The existing implementation relied on many JavaScript libraries for which replacements had to be found or written for WasmGC.

En dan met verderop:

Lastly, they found that years of optimizing had caused the codebase to be over-fitted to JavaScript. For example, they had a core data structure in Sheets which was blurring the lines between arrays and maps. This is efficient in JavaScript, which automatically models sparse arrays as maps, but slow on other platforms. So they had to rewrite the code in a more platform-agnostic way.

De code die omgezet is naar WasmGC is dus de JavaScript codebase die uit de originele Java codebase gewonnen was, maar zich daar inmiddels wijd en ver van gedistantieerd had.

Overigens- sailliant detail wat uit het originele artikel blijkt:

Het geheel naar Wasm overzetten bleek 40% TRAGER dan de JS versie.
Het ontwikkelteam moest enorm veel optimalisaties doorvoeren om de performance daadwerkelijk beter te krijgen. Voornamelijk optimalisaties aan de kern van de Wasm execution engine in Chrome. En één heel poignante: regexes afhandelen door uit de Wasm wereld terug te keren naar de JS wereld en vanuti daar de native implementatie in de browser engine aan te roepen, ipv de in hun Wasm binary in gecompileerde re2j regex engine te gebruiken.

Wat WasmGC hier dan ter tafel heeft gebracht? NUL KOMMA NUL
Naast dan het flienterdunne excuus waarmee ze andere browsers weer eens een performance-nekschot kunnen verkopen.

[Reactie gewijzigd door R4gnax op 22 juli 2024 15:58]

[Ruuddie]

Wat ik hierin lees is dat Google sneller wil bewegen dan de rest van de partijen, omdat zij meer afhankelijk zijn van deze technologie. De andere partijen in deze workgroup hebben geen site met miljarden bezoekers en hebben daardoor misschien ook minder noodzaak om dit snel door te voeren.

Lijkt me niet perse iets heel duisters van Google?

[Pim_t]

Je bedoeld precies hetzelfde als wat Microsoft ooit deed met Internet explorer, waardoor je websites kreeg die ook alleen maar met internet explorer helemaal goed werkten. Het is nogal makkelijk om zelf iets nieuws te verzinnen en dat gelijk te gebruiken en zo de concurrentie op achterstand te zetten. Ofwel misbruik maken van je enorme marktomvang.

[Horatius]

Vind ik naïef ingesteld, door de combinatie van producten heeft Google deze mogelijkheid. Ze hebben voorkennis en brede macht.
Niemand kan hiermee concurreren, hoogstens Microsoft met web office. Doordat zowel chrome als Google Workspace onder hetzelfde bedrijf vallen kunnen ze elkaar voordeel geven tov concurrenten. Laat dat nou een probleem zijn onder de DMA.

Daarnaast de vraag of Google niet veel meer te zeggen heeft in die groep dan de andere partijen. Wat zou maken dat ze van nog meer kanten de concurrentie kunnen dwarsbomen of oneerlijk voorlopen.

[markg85]

Ik snap de arrogante houding van google wel. Hey web met aannemen van nieuwe features is zo'n lang traject geworden (6 jaar voor deze feature) dat je als browser bakker er op een keer ook wel de pee in krijgt en gewoon je eigen ding doet en daarmee forceert.

Probleem is wel dat google dit steeds doet en ook steeds vaker met duidelijke eigen belang redenen waardoor het web wel langzaam stapsgewijs aan het veranderen is naar een weg hoe google het graag wil zien.

"Vroegah" hadden we microsoft die dit ook deed toen internet explorer heer en meester was.

[Pim_t]

Google begint als bedrijf steeds meer te lijken op het Microsoft uit de Netscape periode. Het lijkt er op dat chromium steeds meer gepushed wordt als de de facto browser engine in plaats van gewoon de standaarden te gebruiken die alle browsers ondersteunen. Dus net als vroeger met internet explorer.

Ik hoop dat het gebruik van alternatieve browser engines niet nog verder achter gaat lopen zodat er nog meer een monopolie komt. Ik gebruik ook nog steeds firefox en ben er erg blij mee, alleen merk ik soms dat niet iedereen er meer rekening mee houdt dat er meer is dan chromium.

[THETCR]

Volgens mij snapt met niet wat een garbage collector is.
Zodra er wordt gesteld dat de berekeningen worden uitgevoerd met een GC dan weet je gelijk al wat het niveau is.

[ArmEagle]

Met dank aan een link hierboven van MOmax vond ik deze sectie: https://web.dev/case-stud...asmgc#the_solution_wasmgc

adds the primitives needed to compile garbage collected languages (such as Java).

De basis logica is eigenlijk nog steeds Java. Ook toen berekeningen van de server naar de browser gingen (eerder in dat artikel benoemd).

Dankzij deze extra functionaliteiten kunnen ze die code nu dus in Web Assembly omzetten.

Als de basis logica in C++ was ontwikkeld (niet echt een webtaal) dan had Web Assembly al eerder gebruikt kunnen worden.

(Edit; MOmax heeft dit nu ook toegevoegd, en dez11de was sneller)

[Reactie gewijzigd door ArmEagle op 22 juli 2024 15:58]

[THETCR]

JAVA wordt aangehaald als voorbeeld. WebAssembly is niet gebaseerd op JAVA.

Hoe kom je erbij dat de basis logica eigenlijk nog steeds JAVA is?

Ook ten tijde dat JAVA gebruikt kon worden voor de front-end had het een interpreter nodig.

[Reactie gewijzigd door THETCR op 22 juli 2024 15:58]

[sfranken]

Veel mensen halen Java en Javascript door elkaar nog steeds, gok ik.

[THETCR]

Inderdaad. Het is ook niet handig geweest dat ze destijds de naam JavaScript hebben gekozen.
De twee talen hebben niks met elkaar gemeen. JAVA was destijds populair en de heer Eich dacht zo meer engineers over de streep te trekken het te gebruiken.

Maar wasm draait in de basis ook niet op JavaScript. Dus ik snap niet waar die statement vandaan komt.

[sfranken]

Wasm compileert naar een JS wrapped object, als ik de theorie ff snel goed doorheb.

[THETCR]

Nope. WebAssembly is in binary-code en de browser voert het vervolgens uit tegenover de C kernel API's van het OS.

De gehele JS engine is er dus tussenuit, dat maakt het aanzienlijk sneller.

Het idee is dat je zoveel mogelijk talen kan compileren naar WASM.

[sfranken]

hmm, wat ik kan vinden zo snel (https://developer.mozilla...ng_the_package_on_the_web) is dat je het inderdaad compileert maar je alsnog een JS file krijgt. Als ik de C/C++ voorbeelden op dezelfde site bekijkt wordt er daar met geen woord gesproken over echt uitvoeren of draaien.

[THETCR]

De JS file is ter demonstratie hoe je moet interfacen met een WASM file. WebAssembly modules zijn namelijk afgebakend.

[sfranken]

Ik zie waar de verwarring vandaan komt, ik bedoelde namelijk inderdaad het aanroepen/interfacen met WASM code.

[R4gnax]

Dat was niet Eich's keuze, maar dat was de keuze van de bedrijfsorganisatie van Netscape.
Eich had de nieuwe taal origineel de naam LiveScript meegegeven.

Het was ook Eich's persoonlijke theorie dat de naamswijziging was gemaakt om gebruik te maken van de populariteit van Java wat toen in de openingsdagen van de dot-com boom juist populair was geworden, maar daar hadden ook gerust nog andere zaken aan ten grondslag kunnen liggen.

[Reactie gewijzigd door R4gnax op 22 juli 2024 15:58]

[dez11de]

Omdat de calculation engine van Google sheets is begonnen als een Java applicatie.

[aikebah]

Alleen is die begonnen als een javascript applicatie, niet als een java applicatie voor zover mij bekend.

[dez11de]

Uit het gelinkte artikel:

The Google Sheets calculation engine was originally written in Java and launched in 2006. In the early days of the product, all calculation happened on the server. However, from 2013, the engine has run in the browser using JavaScript.

[aikebah]

Ah... had ik helemaal gemist dat het ooit als een serverside computed spreadsheet begonnen is.

[THETCR]

Dat maakt het een stuk duidelijker, dankjewel voor de opheldering.

[Swindowmasher]

Ik heb in mijn gebruik nooit een delay gehad op berekeningen, denk ik. Dat is toch gewoon instant?

[Icekiller2k6]

Met wat voor dataset werk je? gebruik je cross sheet input?
Ik heb al vaak gehad dat ik een verplichte "refresh" moest doorduwen...

[ajsietsma]

Ik heb dit niet getest, maar ik verwacht dat cross sheet input I/O gelimiteerd is want het moet data lezen uit de cloud.

Echter, je kunt in google sheets ook rustig een lineaire regressie draaien bijvoorbeeld en dan gaat 'ie toch wel vrij snel (i.e. een paar honderd data punten) stotteren. En de size limit is of 10 miljoen cellen...

[Reactie gewijzigd door ajsietsma op 22 juli 2024 15:58]

[McBacon]

Als je 10 miljoen cellen nodig hebt dan is een spreadsheet daar sowieso niet echt geschikt voor eigenlijk. Dat zijn zeg maar 10000 kolommen en 1000 rijen, niemand gaat daar ooit nog élke cel van bekijken. En een foutje in elke willekeurige cel ga je ook niet zomaar meer terug vinden.

[avboven]

Ik vermoed dat veel mensen tegenwoordig Sheets als database gebruiken nadat de (gratis) native database (ik weet niet meer hoe die heette) uit Google Workspace werd gehaald.

[CivLord]

Met zoveel gevulde cellen zijn ze waarschijnlijk automatisch gevuld en zal fout in één cel een fout in een hele rij of kolom betekenen.
Of het is een dataset afkomstig uit een datalogger. Dan ga je daar analyses op uitvoeren en ga je ook niet elke cel afzonderlijk bekijken.

Bij bv. een weerstation die elke seconde 17 parameters logt zit je binnen een week al op 10 miljoen afzonderlijk gegevens.

[kuurtjes]

Snelheids winsten bij dit soort zaken merk je voornamelijk bij dingen die langer duren.

[bommel]

Waarom alleen Chrome en Edge? Is dat weer zo'n bewuste actie om de eigen browser te bevoordelen of ontbreekt er daadwerkelijk nog iets in bijv. Firefox ?

[R4gnax]

Firefox ondersteunt de WasmGC extensie voor Wasm nog niet.
Komt omdat dat pas redelijk nieuwe technologie is, die eigenlijk nog lang niet 'af' is maar die Google zoals ze voorheen met Web Components 'versie 0' ook gedaan hebben, weer eens in hun eigen product live in gebruik geduwd hebben.

Ja- dit is inderdaad (wederom) een verkapte versie van a) hun eigen browser bevoordelen en b) hun zinnetje doordrammen en andere browsermakers verplichten hun specificatie te implementeren, of bij het publiek af te gaan.

[Reactie gewijzigd door R4gnax op 22 juli 2024 15:58]

[karelvandongen]

Ik vind het toch echt fijner als de Microsoft variant, waarbij er door internet explorer ca 5 jaar nauwelijks ontwikkeling in standaarden plaats vond !! En dat heeft chrome wel mooi doorbroken. En daardoor kan ik nu gelukkig een Google/Microsoft/Apple vrije open source omgeving hebben.

[YGDRASSIL]

Chrome is van Google dus hoezo een Google vrije open source omgeving?

[karelvandongen]

chromium , en dan vooral browsers die daarop zijn gebaseerd ....

[Reactie gewijzigd door karelvandongen op 22 juli 2024 15:58]

[R4gnax]

Chromium heeft geen open-source governance maar staat nog steeds direct onder controle van Google. Als zij een bepaalde agenda hebben waar ze bedrijfsmatig Chromium willen hebben, dan is dat waar Chromium heen zal gaan - punt.

Bedrijven en andere organisaties die Chromium gebruiken om hun eigen browser uit te geven, zijn bedrijven en andere organisaties die niet de capaciteit hebben om Chromium zelf in onderhoud te nemen en zullen ook niet snel downstream forks die sterk divergeren van Google's Chromium.

Daarnaast bevat Chromium weliswaar niet de Chrome en Google branding - maar bevat het toch echt nog steeds ingebakken referenties naar diverse services van Google. Als je die er uit wilt hebben en daadwerkelijk vrij van Google wilt zijn - zul je iets als Ungoogled Chromium in de arm moeten nemen.

[karelvandongen]

Je gaat er nu van uit dat heel chromium slecht is !. in de praktijk is misschien 1 a 2 procent slecht (tracking ad's etc), en die kun je er dus prima uit forken. En dan een goede browser over houden. Er zijn meer dan genoeg voorbeelden.

[R4gnax]

Ja- en die geef ik dus ook aan - o.a. Ungoogled Chromium.

Dat doet echter niets af aan het feit dat Google nog steeds a/h roer staat van Chromium. Projecten zoals Ungoogled hebben afdoende in hun mars om o.a. tracking en telemetry er uit te slopen, maar het gaat moeilijk worden zodra Google besluit om andere zaken door te voeren waar je het wellicht niet mee eens bent. Zo is er de controversiële overgang naar versie 3 van de 'Manifest' API voor browser extensies, die de network interception APIs - waar goede ad-blockers heel zwaar op leunen - onder het mom van beveiliging uitschakelt. Wat als Google nou eens besluit om die API daarna ook compleet uit de code te verwijderen? En, ongehinderd door het bestaan van die API wijzigingen door blijft voeren aan de networking code, waardoor een fork het verschrikkelijk moeilijk zou gaan krijgen om die code terug ingebracht te krijgen?
Zo maar een simpel, doch zeer actueel, voorbeeld.

Ik neem dus niets aan, maar jij moet beter lezen en beter kijken naar de bredere situatie.

[karelvandongen]

https://vivaldi.com/blog/...brequest-and-ad-blockers/ en de andere zullen vergelijkbare dingen doen. Ik zie niet echt waarom dat ineens een probleem zou vormen ? . Echt er komt dan wel een gezamenlijke patch set, om dat te verhelpen.

[R4gnax]

En al die andere organisaties die die moeite moeten doen om Chromium van patches te voorzien zodat deze buiten de invloedssfeer van Google zou kunnen overleven, betekenen dan dat jij "daardoor nu gelukkig een Google-vrije open-source omgeving" hebt.

Niet het feit dat het Google is die MS van de troon aan de top van de browser-wereld gestoten heeft.

En hoe dat dat verder met het al dan niet verder uit ontwikkelen van webstandaarden verband houdt?
Geen idee. Non sequitur, voor zover ik kan zien.

[Reactie gewijzigd door R4gnax op 22 juli 2024 15:58]

[karelvandongen]

Google heeft het wel mogelijk gemaakt (na dat ze van safari de code hadden gepakt, en deze was weer op khtml gebaseerd), en daar ben ik ze dankbaar voor. Want ik heb de source code van internet explorer nooit kunnen inzien. En dat andere dit weer gebruiken om iets beters te creëren kan ik alleen maar aanmoedigen, en maakt de circle ook rond.

[Reactie gewijzigd door karelvandongen op 22 juli 2024 15:58]