Livebook crashing attempting to open a livebook.

[Adzz]

Environment

• Elixir & Erlang/OTP versions (elixir --version): elixir 1.13.3-otp-24, erlang 24.1.7
• Operating system: mac / unix
• How have you started Livebook (mix phx.server, livebook CLI, Docker, etc): livebook server
• Livebook version (use git rev-parse HEAD if running with mix): Livebook 0.5.2
• Browsers that reproduce this bug (the more the merrier): firefox
• Include what is logged in the browser console: nothing
• Include what is logged to the server console: nothing

Current behavior

I have been experimenting with generating livebooks from module docs. I generated a livebook from Elixir's Enum module, but I cannot open it. Livebook hangs for a long time.

Expected behavior

That I can open the livebook 😄

[josevalim]

I don’t think we have the commit SHA in this repo. Are you running a fork? In any case, can you make sure you have this commit applied: a70f53d

[Adzz]

Yea apologies I pasted the wrong commit sha originally, I updated the comment with the version.

I just tried cloning the repo and using latest master, so git rev-parse HEAD = a280224

I still get the same issue.

UPDATE - It did eventually load this time, it just took a long time. The livebook also struggles to evaluate all the cells.

I wonder if the livebook is just too large or something

[jonatanklosko]

It's related to notebook size, yeah.

The initial hang during import/navigation is caused by editor initialization, which takes a long time for so many editors. Actually, the initialization happens when mounting hooks, so the session page is only shown after all editors are initialized; we could defer the initialization (though a bit tricky), so that we show session skeleton instead, but this doesn't change the fact that all the initializations need to happen and we won't avoid it.

As for slow evaluation, patching the DOM takes a long time (0.5s - 2s for a single diff). Maybe we could improve some of that with more sateful components.

[Adzz]

Thanks for digging into it more! I was a little suprised because I didn't think the notebook was that large - certainly within the realm of what vscode should be able to handle. I assume it's the number of elixir cells that are problematic, rather than too much markdown eg?

We could perhaps add some guidance somewhere around max size if nothing else!

[jonatanklosko]

I assume it's the number of elixir cells that are problematic, rather than too much markdown eg?

Yeah, note in our case it's not a single code editor, but a bunch of those, and unfortunately mounting an editor is a synchronous operation.

Your case is a bit specific because you took an existing large notebook-like file, but most of the time people write notebooks in the first place, and I think they would notice if things slowed down.

There's likely no obvious max size, because it heavily depends on how fast the browser operates, so it will vary across hardwares.

[Adzz]

Yea appreciate my use case may be unique. The reason for generating livebooks at all is so you can have one source of truth for all documentation.

One idea that might be very naive - currently each Elixir cell is a whole Monaco editor, but presumably the editor allows multiple buffers - as in in VSCode I can press ctrl+n and a new file / buffer thing appears.

Could we have one Monaco instance on the page and have each subsequent elixir cell be a file / buffer?

[jonatanklosko]

@Adzz it is possible to create a single editor instance and multiple document models, then switch the current model. This allow for implementing tabs (ref). In our case, however, we need to all the documents at once, so we need multiple instances.

Jose pointed out that we could initialize editor for markdown cells lazily, because it's hidden by default, so that's one thing I will look into.

[Adzz]

Oh cool, tabs is exactly what I had in mind

however, we need to all the documents at once,

I assume the missing word is "load" - either way I trust you.

[jonatanklosko]

Ah sorry, I meant that we need to show all the documents at once, or in other words have all the tabs open (each cell being one).

[jonatanklosko]

With #1102 it should open more quickly, though initializing all the code editors will still take a moment. As for evaluation, I don't think we can easily avoid full DOM patches without breaking the page down into more stateful components and pushing updates to them directly, but orchestrating all of that is too much complexity. Maybe some future optimisations in LV will help with that.

All that said, I'm gonna close this one :)

[RichMorin]

I'm confused by this: "in our case it's not a single code editor, but a bunch of those". Are you saying that Livebook is setting up an instance of a single code editor (eg, Monaco) for each cell, or that it is setting up instances of multiple editors for each cell? If it's the latter, maybe a user preference could specify which editor(s) are desired.

[jonatanklosko]

Are you saying that Livebook is setting up an instance of a single code editor (eg, Monaco) for each cell

Correct, each cell has its own editor because they are visible all at once (as opposed to tabs in VS Code, for example).