Pluto.jl: Low hanging fruit to make the UI faster?

[fonsp]

This notebook is massive, and you start to notice UI slowdowns:

https://github.com/mitmath/18S191/blob/master/homework/homework3/hw3.jl

There is a general sluggish feel, but the easy way to see it is to drag around the selection box, since this triggers notebook state updates.

I don't want any crazy optimizations, but maybe there is some very simple thing to optimize? Pure components? or something?

[Pocket-titan]

Idk why the link changed but it's now: https://github.com/mitmath/18S191/blob/master/homework/homework3/hw3.jl.

I'm not noticing any slowdowns with the selection area, but I do notice that adding or removing a cell is sometimes taking "too much" time (~400ms). Do these things also feel sluggish for you?

I think one way to fix this is to move these "local" notebook actions (add cell, remove cell) to the frontend, so instead of asking the server for a new cell/to delete a cell & having to wait for a response, you set the state immediately & just "notify" the server that you did these things (which can then propagate to other clients). For deleting a cell, this is relatively easy, adding a cell locally would however require you to also create the cell on the frontend (not sure if that's an issue or not).
Trying to think of ways this could cause the UI to desync w the server, but I think we'd be good?

(If you didn't mean this by things feeling sluggish you can just ignore this)

[fonsp]

Yes that's a good idea, but i meant that every notebook state update (like the docs query after every keystroke) takes too long for react to process. Maybe only on firefox? I am hoping that there is some super simple change that we can make, like Component -> PureComponent and boom its fast.

[Pocket-titan]

I tested it on firefox and I'm not noticing any difference compared to chrome tbh, once every while (i.e. first time running a notebook) the docs query is "kind of slow" but after that it's good 2 go for a while (and the slowness is from the network query, probably).

Replacing Component with PureComponent could be nice, but I'm not sure if that would matter - I was thinking we could use the Preact Devtools + the browser extension (https://preactjs.github.io/preact-devtools/) to profile the Preact side, but it doesn't appear to be exported in the ESM packages & would require a bit of adjusting to make it work w web modules (at least from what I can see).

The other thing we could use for profiling is https://github.com/welldone-software/why-did-you-render. It's made for React but it should in theory work with Preact too, but the same story applies: doesn't look like it's made for web modules :/ (btw the first picture on the readme shows a great example of why a PureComponent alone might not make that much of a difference - a PureComponent implements shouldComponentUpdate but it only diffs shallowly by default)

I can take a look tomorrow & see if these solutions want to play nice w web modules? + let me know if you are interested in the "fix" I proposed before this

[fonsp]

Sounds like you need a slower computer 🙃

let me know if you are interested in the "fix" I proposed before this

No, we don't do these optimizations yet because it makes things too messy.

This issue was really more of a note to self: go through the code and look for something simple that we overlooked. So if the preact dev tools don't work straight away (thanks for tryign!) then we leave it

[fonsp]

https://www.notion.so/optimize-performacne-frontend-c6c59d06d4dc49019ae5ccdd04d795f7