4 ms·

Where in that stack is the biggest loss of performance? DOM? Javascript? Browser? Or is it because everything needs to sync to the cloud as you edit it?

brabel 2y ago
I think it's just the way web apps are architectured. If you use vanilla JS you can make the browser render stuff really fast even if you change the DOM, as long as you do it efficiently (don't update ALL the DOM on every change!). But I bet Google uses some reactive framework that keeps a bloody copy of the whole DOM in memory, so when you throw 30MB of content into the DOM, that copy that was meant to make things faster starts being the bottleneck.
jakub_g 2y ago
IMO the biggest problem is simply that nothing is tested anymore on big inputs, and that frameworks and the modern way of writing code hide the complexity. Also, in the past you had to care explicitly about how much memory you allocate etc. which stopped you to think. Now you can pretend you have infinite resources because everything happens implicitly. Compounded with this [0]: > O(n^2) is the sweet spot of badly scaling algorithms: fast enough to make it into production, but slow enough to make things fall down once it gets there you get what you get. Ever opened a GitHub pull request with 2000+ files changed? It hangs the M1 MBP. The solution is probably not rocket science, if someone really prioritized the fix. [0] https://twitter.com/BruceDawson0xB/status/1120381406700429312 https://twitter.com/BruceDawson0xB/status/112038140670042931...
mike_hearn 2y ago
It's going to be a mix of: 1. JS doesn't support multithreading, nor many other features that are useful for performance (e.g. mmap). This severely limits what you can do and makes it hard to scale up by parallelizing. 2. JS is a very pointer heavy language that was never designed for performance, so the CPU finds it harder to execute than old-school C++ of the type you'd find in Word. It's hard to design tight data structures of the kind you'd find at the core of Word. 3. The browser's one-size-fits-all security model sacrifices a lot of performance for what is essentially a mix of moral, legal and philosophical reasons. The sandbox is high overhead, but Docs is made by the same company as Chrome so they know it isn't malicious. They could just run the whole thing outside of the sandbox and win some perf back. But they never will, because giving themselves that kind of leg up would be an antitrust violation, and they don't want to get into the game of paying big review teams to hand out special Officially Legit™ cards in the same way that desktop vendors are willing to do. 4. The DOM is a highly generic, page oriented structure, that isn't well suited for app-like UIs. As a concrete example Chrome's rendering pipeline contains an absolute ton of complexity to try and handle very long static pages, like tiled rendering, but if the page takes over rendering itself like Docs does then all this just gets in the way and slows things down. But you can't opt out (see point 3).
- skydhash 2y ago
  Or it's just using the wrong tool for the job. With Google's resources, they could build a UI framework that runs on top of OpenGL and have people download an app built with it instead. Next, we'd have people building interfaces on top of latex.
  - mike_hearn 2y ago
    They already built several UI frameworks that run on top of OpenGL. Most obviously, Blink Chrome's HTML renderer runs on top of OpenGL :) Also, Docs uses a custom UI framework already. It implements all the UI controls itself, the browser is only really used for rendering text and styled boxes. I remember the first version of Docs when it was called Writely used the browser's built in editing support but they had to abandon it because it was too buggy, so they moved to using JS to lay out every character and draw their own cursor. It was considered wild and crazy at the time but Chrome was getting fast enough to make it work. Of course, it's more efficient to have editing be implemented fully in C++ but browser makers never managed to make that work properly, so, slow path it is.
    - telotortium 2y ago
      Google Docs has switched entirely to Canvas for several years at this point: https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
constantcrying 2y ago
>Where in that stack is the biggest loss of performance Exclusively the minds of developers and the stance of management. It is of course possible to built responsive, high quality and performance websites. But that is hard, much, much harder than to make something work, which maybe takes a few seconds to load, sometimes doesn't work quite right and can be a bit tedious to use.

brabel 2y ago

I think it's just the way web apps are architectured. If you use vanilla JS you can make the browser render stuff really fast even if you change the DOM, as long as you do it efficiently (don't update ALL the DOM on every change!). But I bet Google uses some reactive framework that keeps a bloody copy of the whole DOM in memory, so when you throw 30MB of content into the DOM, that copy that was meant to make things faster starts being the bottleneck.

jakub_g 2y ago

IMO the biggest problem is simply that nothing is tested anymore on big inputs, and that frameworks and the modern way of writing code hide the complexity. Also, in the past you had to care explicitly about how much memory you allocate etc. which stopped you to think. Now you can pretend you have infinite resources because everything happens implicitly. Compounded with this [0]: > O(n^2) is the sweet spot of badly scaling algorithms: fast enough to make it into production, but slow enough to make things fall down once it gets there you get what you get. Ever opened a GitHub pull request with 2000+ files changed? It hangs the M1 MBP. The solution is probably not rocket science, if someone really prioritized the fix. [0] https://twitter.com/BruceDawson0xB/status/1120381406700429312 https://twitter.com/BruceDawson0xB/status/112038140670042931...

mike_hearn 2y ago

It's going to be a mix of: 1. JS doesn't support multithreading, nor many other features that are useful for performance (e.g. mmap). This severely limits what you can do and makes it hard to scale up by parallelizing. 2. JS is a very pointer heavy language that was never designed for performance, so the CPU finds it harder to execute than old-school C++ of the type you'd find in Word. It's hard to design tight data structures of the kind you'd find at the core of Word. 3. The browser's one-size-fits-all security model sacrifices a lot of performance for what is essentially a mix of moral, legal and philosophical reasons. The sandbox is high overhead, but Docs is made by the same company as Chrome so they know it isn't malicious. They could just run the whole thing outside of the sandbox and win some perf back. But they never will, because giving themselves that kind of leg up would be an antitrust violation, and they don't want to get into the game of paying big review teams to hand out special Officially Legit™ cards in the same way that desktop vendors are willing to do. 4. The DOM is a highly generic, page oriented structure, that isn't well suited for app-like UIs. As a concrete example Chrome's rendering pipeline contains an absolute ton of complexity to try and handle very long static pages, like tiled rendering, but if the page takes over rendering itself like Docs does then all this just gets in the way and slows things down. But you can't opt out (see point 3).

skydhash 2y ago
Or it's just using the wrong tool for the job. With Google's resources, they could build a UI framework that runs on top of OpenGL and have people download an app built with it instead. Next, we'd have people building interfaces on top of latex.
- mike_hearn 2y ago
  They already built several UI frameworks that run on top of OpenGL. Most obviously, Blink Chrome's HTML renderer runs on top of OpenGL :) Also, Docs uses a custom UI framework already. It implements all the UI controls itself, the browser is only really used for rendering text and styled boxes. I remember the first version of Docs when it was called Writely used the browser's built in editing support but they had to abandon it because it was too buggy, so they moved to using JS to lay out every character and draw their own cursor. It was considered wild and crazy at the time but Chrome was getting fast enough to make it work. Of course, it's more efficient to have editing be implemented fully in C++ but browser makers never managed to make that work properly, so, slow path it is.
  - telotortium 2y ago
    Google Docs has switched entirely to Canvas for several years at this point: https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...

constantcrying 2y ago

>Where in that stack is the biggest loss of performance Exclusively the minds of developers and the stance of management. It is of course possible to built responsive, high quality and performance websites. But that is hard, much, much harder than to make something work, which maybe takes a few seconds to load, sometimes doesn't work quite right and can be a bit tedious to use.