Not to my exact code, but I’ll post a reproducible example.
tmbb
tmbb
Just to add to the discussion: this should probably be even more obvious, but the amount of data being sent in even simple form validations for nested forms with ~15 user-facing inputs (plus a bunch of hidden fields to implement moving and deleting items in the form) sends to the server around 10kB of data and receives around 10kB of data, which naturally scales up when you increase the number of items in the form.
Honestly, up until this performance problem (this is my first “big” phoenix form) I had never looked at the message size because it’s not too proeminent in the server logs and I don’t have a good intuition in converting nr of characters to kB (the logs show the received map but not the message size). I find it a little scary that I’m sending so much data upd and down for simple form validations. I think that for these amounts of data I’d have to think carefully about network bandwidth and prices… Of course, this is still all dwarfed by more data-intensive apps such as audio streaming or such, but here I am trying to get dynamic forms working and then comparing it to audio streaming (!), even if for short bursts when the user is actually editing the form.
Again, I don’t remember the data transfer problems being highlighted in the phoenix docs: everyone talks about how “minimal” the diffs are (and they are indeed close to minimal, no question about that), but then everyone shows examples of very small forms with minimal data transmission. So I guess that leavs less experienced users like me surprised by how much data can be transfered in more complex UI.
So I guess I’ve been surprised on both fronts:
- How slow the DOM updates can be for complex UIs
- How much data can be transferred during form validations which I think are pretty simple. The solution, of course, would be to only validate the form on submit (the data must be sent to the server at some point), but that complicates a lot of things in the UI (designing custom events to add sub-items instead of depending one Ecto’s
:sort_param). And isn’t the whole point of LiveView to get flashy real-time form vaidations? That’s one of the things more often shown in the demos…
I think a couple of things are needed:
- A warning about Morphdom’s performance on “large” lists - definitely not something I’d expect on lists of < 100 components (even if the components are quite complex)
- A warning on data transfer amounts
- Adding the amount of transferred data in the logs for the event handlers. Seeing how many kBs of data we’re sending every second (or whenever you want to validate your form) can be very illuminating
I’ll post some issues to the LiveView repo to suggest these documentation and log improvements.
Sorry, this is turning into a rant against LiveView, but that’s not how one should interpret this thread. It’s more of a rant about the documentation not being clear about the pitfals of using LiveView for what I consider “simple” UI.
(I guess I won’t be using LiveView for this application)
0
josevalim
Creator of Elixir
I don’t think the list size is the issue but rather its contents. DOM is a tree and you are more likely being punished by the tree than the list size. Morphdom works by comparing node by node and using IDs may help it to avoid discarding changes.
Keep in mind you can track a lot of this in the Network tab already of the dev console, where you get payload sizes per WebSocket message, but it would be beneficial making this information more upfront too, so 
.
Other than that, the comprehensions contents are sent as a whole if the comprehension changes, because computing the difference between two arbitrary lists can be resource expensive, so you need to resort to either LiveComponent or streams, as already explored. But these should be better documented. I will submit more docs later today.
8
tmbb
Indeed, that is obvious. I should have made myself more clear:
- In reality I’m not updating a list of 100 components. I’m updating a deep DOM tree with 100 branches in which each branch has more many children
- But when planning to use LiveView for my app I was thinking “I’m just rendering a list of 100 things, how bad can it get?”. And during initial testing I was actually building the forms manually, so they never got to “production size”. Only when I decided to populate the system with synthetic data did I notice the horrible performance.
That I did expect, and it might turn out ok for “simple lists” of components. But then I have actually implemented components that allow you to delete (using the “checkbox disguised as button” trick) and move up and down (again, using buttons with the “checkbox disguised as button” trick) each child in a has_many assoc, which means 5 extra input fields per child. All these inputs are in a sense “dynamic”, and need to be sent to the server for validation and back from the server after validation. And because the lists are somewhat deeply nested (3 levels deep) and due to the way Plug encodes the parameters, each of the deep feelds consumes a lot of space in the message. For example (imagine the following is URL-encoded, which only increases them message size): `project[tables][0][columns][0][choices][0][name]=ChoiceName". And now imagine this repeated for 3 attributes per choice + 5 “hidden” attributes required for the sorting. This is exactly the way a form is sent to the server on HTTP requests, but that happens once in a while when the user is already primed to wait for the server “to do its stuff”.
In my optinion, this has very dangerous performance characteristics because it’s totally manageable for simple things but prohibetively expensive for the slightly more complex things. It’s a linear algortithm with a constant big enough that it can’t be noticed for small inputs but quickly gets very noticeable in a part of the UI the user would expect to be very fast.
When I have the time, I should publish a screencast (together with the code and the message sizes) as a warning about what can happen when one treates LiveView updates as “free”, like I was naïvely doing.
Yes, I know this and that’s how I’ve been monitoring the message sizes, but the explicit promise of LiveView (which I know believe to be misleading) is that you just write elixir code, forget about Javascript and the right thing will happen (those are not exact words from anywhere, but it’s the general vibe of bothn the docs and lots of talks I’ve seenH). I forgot about javascript and the browser so much that I only looked at server logs and forgot about looking at the browser completely, including the network console.
Again, please don’t take this as an attack on LiveView’s design decisions… I certainly wouldn’t kow how to do it better, a is obvious from my UndeadViews/Vampyre experiments from 2018. It’s instead an attack on the mismatch between the “promises” made in educational materials regarding performance and what actually happens in the real world as soon as you deviate a bit from the small tech demos in the talks.
0
tmjoen
We switched our block editor from Vue to LiveView some years ago and had some real pains with super large forms. These were also complex, nested forms. As a last ditch effort before going back to Vue we split out all our assocs to their own forms. So when saving the “main” form, we traverse and combine all the other forms on the page then add it to the main changeset. It was a bit of a challenge to make it all work but the speed up was enough for us to stay with LV.
2
tmbb
So did you have something like this:
<form>
<input ...>
<input ...>
</form>
<form id="child1">
<input ...>
<input ...>
</form>
<form id=grandchild1">
</form>
<form id=grandchild2">
</form>
<form id="child2">
<input ...>
<input ...>
It seems like a good idea, that would allow you to validade changes in one form at a time.
0
Zurga
Maybe it will help only with the message size, but I wrote a guide that explains how to switch to MessagePack encoding in the socket. I use it in production for a mobile first web app that sometimes has bad internet speed on the client side.
This will shave around 25% of the message size at the cost of message legibility in the developer console and a small decompression overhead.
0
josevalim
Creator of Elixir
And to be clear, that’s not necessarily a problem either, the tricky part is that those are dynamic branches. It seems you are updating a list with a dynamic list with a dynamic list with a dynamic list inside. This is neither common nor simple.
This should not be a concern payload wise, enable compression on the socket and you should be good to go.
In any case, looking at the above, it does make me wonder indeed if three level deep association in a single form is the best design and/or UX. I assume it can get confusing for the user to manage several levels of a hierarchy at once (I think this is the first time I see that many levels in a single form!) Someone already suggested to break the forms apart but you can also do something like this:
TABLE
[ Column EDIT DESTROY ]
[ Column EDIT DESTROY ]
[ Column EDIT DESTROY ]
[ Column EDIT DESTROY ]
[ NEW ]
Where the first level of management is not really a form but something that allows you to manage the children.
It also made me realize that, because you are validating the whole form and all associations at once as the user fills in, the validation on the server itself may become expensive too. It would be similar to an e-commerce platform where you have a single form for the categories, then products, then the variants, and then the images, all at once. I wouldn’t be surprised if another performance issue pops up even if the UI one is addressed.
Anything that runs on platform XYZ will, by definition, require you to care about XYZ at some point. At some point, an Elixir dev may need to care about the Erlang VM. At some point, you may need to care about Unix if you deploy to Unix. And, if you are running in the browser, at some point you will need to care about it too.
Btw, after thinking about this problem a bit, I was wondering if part of the issue is because the updates are mostly the same, the diffing is expensive because Morphdom is traversing everything mostly to find out that almost nothing changed. Similar to how comparing two lists for equality will be naturally more expensive if the two lists are equal. I am speculating here though. If someone has a way to reproduce this, I will gladly take a look. I quite enjoy optimization work!
12
tozz
I’ve been running into similar problems, my biggest problem is that you can’t nest forms according to the spec so you’re stuck between not being able to use the nice benefits of the Ecto/Phoenix integration or building custom javascript hooks trying to merge multiple forms (and same thing on the backend side with multiple changesets).
Most of my basic forms usually end up ad 20-40KiB for each validation trip, UUID’s take a lot of space, every dynamic attribute, lists etc. I’m defaulting to LiveComponents to alleviate it but even so the ID’s and dynamic nature of forms causes quite big payloads.
Other things that causes some headaches are that even with state on the server changesets needs to be complete, which makes partial validation and transmission very hard (or impossible).
Streams work ok for read-only data but any time you get into dynamic stuff it becomes quite troublesome with relying on state on the client.
That said it’s still a very nice way of working, but I think there are a lot of gotchas that aren’t very clear from the docs.
3
tmbb
Yeah, I’m looking at GitHub - woutdp/live_svelte: Svelte inside Phoenix LiveView with seamless end-to-end reactivity · GitHub and GitHub - Valian/live_vue: End-to-end reactivity for Phoenix LiveView and Vue · GitHub but I’m a bit afraid of the fact that to render useful content on initial page load they seem to depend on server-side rendering, which requires having a NodeJS server running in parallel with the BEAM. which I really, really don’t like. However, that is always a problem with client-side JS frameworks, whether used with LiveView or not…
BTW, even with a “single” list level I’m getting payloads of ~190kB with a list of 60 sub-items (~180 input widgets). And I don’t think I want to have those kinds of diffs…
0