I’m currently seeing some issued with our admin interface, where people on Intel CPU’s being shown the “the tab has crashed” kind of dialog when using a LiveView form. The background is that we use the Ecto sort and delete params, interactions need to be processed, otherwise I’d just change it to not have any interactive features.
The issue is not on the receiving end, that’s significantly much faster, but when LiveView does its processing before dispatching to the server. This screenshot is on a M3 Pro.
I don’t know why dispatchClickAway is wrapping all this, since there’s no such event on the page
I tried digging deeper but as you know with JS, it’s usually a very long list of anonymous functions with minified names.
Looking at Node count it varies between 80-800K. Yes that’s 10x, for some reason LiveView or Chrome, unclear which, don’t clean up the tree after navigating/getting updates. It seems to be reliant on a GC to run.
The form is quite straight forward.
Schema (120 entries),
|---- SubSchema (can vary, but between 0 and 10 items)
|---- SecondSubSchema (0-3 items)
So at most one level deep, but you can add and remove them dynamically. Processing times on the server side are fast enough that it doesn’t matter, less than 20ms, even in dev-mode.
Curious as to if people have some good ideas on how to debug this.
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.
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.
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.
Curious as to if this will be released soon, I did see you added it to the 1.0 branch and it’s in the changelog, but perhaps there’s something blocking 1.0.6?
). And I’d argue this isn’t even a big form, given the context of building an admin interface.
