Running into JavaScript timeouts with LiveView (browser tab hangs) and medium sized forms

We’d need to know a lot more. 80k DOM nodes is extreme, 800k is likely to be a showstopper in general, but I haven’t measured. facebook.com timeline for example is on the order of 4-5k DOM nodes. What is your DOM node count on dead render/first mount?

I dug into this some more, my numbers are from the Chrome Performance Monitor, and it seems that is doing some weird counting, or it keeps some internal state that isn’t represented in the actual tree.
Doing a simple document.querySelectorAll('*'); returns 19k nodes. Looking at just input it’s 4600 (actually exact) and of those it’s 2450 that are hidden (inputs_for generated with the exception of the needed _sort / _delete ones for Ecto)

Looking at execution time pushInput is the one function taking up time, below is a screenshot of dynamically adding three new “SubSchemas” to the form on a M1.

Screenshot 2025-02-28 at 07.21.43906×141 22.5 KB

Happy to supply any other data you might need, and thank you for all the hard work in the ecosystem, using Phoenix and LiveView has been a bliss in general

@chrismccord I found the “problem” (at least one that is really really tangible).

In serializeForm there’s a section that really destroys performance.

// view.js
let elements = Array.from(form.elements);
for (let [key, val] of formData.entries()) {
...
  let inputs = elements.filter(input => input.name === key)
  let isUnused = !inputs.some(input => (DOM.private(input, PHX_HAS_FOCUSED) || DOM.private(input, PHX_HAS_SUBMITTED)))
  let hidden = inputs.every(input => input.type === "hidden")
...
}

That first filter is very costly, in my form that’s a total of 22036236 iterations (I added a counter ). And I’d argue this isn’t even a big form, given the context of building an admin interface.

I’ve run into similar issues with JavaScript timeouts before—optimizing event handling and reducing unnecessary re-renders helped in my case. Are you using debounce or throttle for frequent updates? Hope you find a fix soon!

How is that 22 milion iterations?
The square root of that is something in the order of 4900, so you have form.elements and formData.entries in the order of 4-5K?

That sounds like a big form in my book?

But if this is the bottleneck for you, you might try to optimize the code yourself and see if you can improve the performance and submit a PR?

As mentioned in the original post, yes it’s 4600 inputs, more than half of them are inputs_for generated and _sort/_delete hidden fields. The form itself is not very large, it’s for building a Questionnaire, each Questionnaire have questions, questions have answer options. Then again, “large” is relative and I might just have a different background. It could very well be that I’m not supposed to use LiveView for this, but it would be truly marvelous if I could.

But if this is the bottleneck for you, you might try to optimize the code yourself and see if you can improve the performance and submit a PR?

Exactly what I’ve been doing, but there’s a lot of moving parts here.
Storing the lookup on input.name saves 4m iterations, but it’s still way too high, but a free optimization (unless it breaks somewhere else of course).

I think if you want really improve the performance, then I think you need to look at changing the algorithm. For example by breaking the O(n^2) algorithm by introducing an other datastructure. For example by parsing the form elements in a map with name as a key.

But you’d have to do some benchmark to see if that has a decent effect.

If you have a lot of text input, then it is highly advisable to disable default attributes like spellcheck spellcheck HTML global attribute - HTML | MDN and autocomplete <form> HTML form element - HTML | MDN

Phoenix does a lot in JS, especially with watching forms and helping with focus and etc. It does a bit to much for my taste and I think it could benefit from doing less on the front end and more on the backend and just leverage messages passing to reconcile states, I believe the cost in increase chatter will be worth it when messages are small.

It would be interesting with a server-first forms solution, it would of course come with its own tradeoffs (like not being able to recover, or at least making it much harder).

Removing this inner loop makes everything work blazing fast, and from what I can tell the only purpose for it is to control what field has been used to trigger showing of errors, which of course is a big UX thing.