You are essentially traveling down the chain of thought that led to Streams. I’d strongly recommend trying the LiveComponent strategy first, and then look into Streams in the future if you feel the need (you probably won’t).
garrison
sodapopcan
Ha yes, I figured you just may know a little more. I sorta remember someone asking the different between a function component and a LiveComponent from a memory standpoint and José saying there is essentially no difference but I can’t find the thread so I very well have misread that. The other stuff I understand, obviously much less overhead than a nested LiveView and I do understand persistent data structures so ya you’re right, that is still some overhead for the “pointer” (I know it’s slightly more complex than that). Though now that I think about it, I did remember a comment (that I also can’t find) where someone was saying that smaller maps are actually fully copied but no idea if that’s true, so basically I’m just piling up all these things I read that challenge what I already thought and decided you were the unlucky one I would ask to clarify 
The solution to my problem is that I should just read The BEAM Book.
0
garrison
I think the simplest way to explain the difference is that LiveComponents maintain diffs of their assigns separately, while function components do not. In other words, function components (I believe) lack the :__changed__ assign which stores the diffs.
Obviously the overhead of this is to store things which are already in-memory, so it’s just the overhead of another map (and we’re back to square one here).
They are also treated differently by the diffing algorithm and on the wire. I don’t know exactly how it works but the impression I got skimming the code is that they’re treated on the client as if they are a root LiveView, so the morphdom invocation for each LiveComponent is separate from the main tree. Or something, not sure.
The fact that they are diffed separately is very important though, because it means the diff can just be %{id => diff} on the wire, without having to worry about where in the DOM that id actually is, because it’s “globally” unique (per page). So there’s a speedup from that too.
I’m sure a maintainer could give you a much more thorough explanation.
I wouldn’t be surprised, there’s always some overhead with keeping references and a point where the tradeoff isn’t worth it. Only maps above (I believe) 32 entries are stored as hash tables (really hash array-mapped tries, a mouthful).
Important to keep in mind, though, that just because the map is copied doesn’t mean its contents are! If you had a large map in a small map and duplicated the small map, the large map would still just be a reference (I assume).
Of course this is made even more confusing by reference-counted binaries, which aren’t copied even across processes…
2
tmbb
I did replace some of the HTML by live components and performance is now much better (patch times ~80-220ms instead of 1500ms), but the delay attributable to the DOM patches (according to the timings given by liveSocket.enableProfiling();) is still noticeable. I’m stil a bit incredulous on why my multi-GHz PC takes so long to patch the DOM. I know I’m not being very smart in the change tracking, but still, it’s disappointing.
I’m seriously thinking of using a normal JS framework instead of LiveView. The only reason I haven’t done it yet is the fact that it would make it harder to use ecto changesets for validation (I’d have to convert the ecto chnagesets to JS somehow, and I’m not in the mood for that).
In any case, I think this problem needs a bit more publicity. I might contribute to the docs warning users of the Morphdom troubles. There are only about 3-4 places on the internet that discuss LiveView’s client-side problems (a youtube video and a couple posts on this forum). Everywhere else sells LiveView as something which will not cause problems for real-world pages, and the main discussion is always centered on the performance impact on the elixir side (“be careful about having too many PubSub messages”, or “be careful about not storing too much state on the server”). But reading the docs I’d never dream about having problems with a webpage with a couple thousands of HTML elements. Worse, it took me 2 days to think of DOM patching as the cause of the performance issues. This speaks more to my ignorance about frontend stuff, but I think the docs should include a warning somewhere.
Giving the situation a more sober look, it seems like even in the worst case (1500ms for 10,000 elements) Morphdom is taking 0.1ms per HTML element. Is that a low? IDK, JS is an interpreted language and the DOM is a big, complex object. So, maybe, shame on me for being surprised…
0
derek-zhou
I feel your pain. However, I am not sure switching to a JS framework will help. Like you said, the bottleneck in in MorphDOM. i’d assume letting the JS part to work more would only make it slower.
0
garrison
That is still very slow. Could you take a look at the socket in devtools and tell us how large the diffs coming over the wire are? I would guess it’s in the MB?
You need to shrink the diffs further. Which parts of the table did you convert to LiveComponents? If it was just the rows and they’re still very large, try wrapping the columns too.
I’m not here to tell you what to do (I am a bigger proponent of client-side rendering than you might expect), but before you head down that path you may want to try searching for the keywords “react table slow”.
Diffing algorithms are not magic, they don’t handle huge amounts of data well.
If the table is large enough you will need to virtualize it (you would have to do this with React too).
0
tmbb
They’re rather big, yeah: from 33kB (if I only change the text inside an input component) to 123kB (when I reorder stuff in the list).
I’m aware that diffing algorithms are not magic, but my hope is that in JS I can have more control over the events I emmit and which parts of the tree I actually need to re-render. But again, I have to think a lot about this.
I can make some trivial UI changes in order to decrease the depth of the components (instead of a LiveView per project I can have a LiveView per table, which is the fundamental unit the user will be working in) and I believe most tables will have < 20-30 columns. I start getting bad times when I reach the 60-80 columns. But I’m always nervous about having these limits (if I expect a size of 20, I’d rather have the UI allow for 200 as a safety margin).
But thanks for your input anyway!
0
garrison
In LiveView the way you control this is with LiveComponents. If only one component changes, then only that component will be re-rendered.
Like I said, if you’re doing this: <div :for={col <- @cols}>{col.text}</div>, and you have 60 columns, all 60 columns will be sent when one changes. If your columns have a lot of dynamic content then this could be expensive. I will say though that 100ms to diff 60 columns still doesn’t sound right to me, so there might be something else wrong. You should inspect the diffs more carefully and see if something else is leaking through that you’ve overlooked.
This is a sign that something is wrong, because re-ordering LiveComponents should be effectively free (on the order of maybe a couple hundred bytes).
0
sodapopcan
Thanks for the response, this is digging much more into stuff I don’t know. I don’t want to address too much as it’s a bit of the main thread, but yes, this all makes sense for the most part. Wasn’t even considering :__changed__ 
To my mind, what the comment I read was saying was saying that it was a full copy. Maybe it wasn’t though? I need to read up a little bit more in order to respond even semi-intelligently.
Thanks!
2
