I’m noticing quite a bit of slowdown when appending messages and replacing elements on a LiveView webpage which has an ever-increasing number of chat messages being displayed. Each incoming message is wrapped in a p tag, and there are multiple spans within the text inside that p tag. As I start get…

Plain eex templates will only be compiled to functions returning iodata – no change tracking for parts of the template. Which is why you’d want to be careful to use .leex everywhere liveview is involved. You are right in that how they are processed is very different, but my understanding is that …

How, exactly, did you implement your components? For example, did you just replace a form element in a LEEX template with a call to render a live component, which did nothing more than render that same form element that was originally created in the main template? In such a case I would love to unde…

[image] mononym: Am I misunderstanding the sequence of events? It seems you are. LiveView does not process the resulting markup after assigns are interpolated. It only processes the templates. .leex templates are processed, so that static parts of the template are taken apart from dynamic par…

Components would solve your issues in this case. The issue is we have to patch the entire LiveView DOM container for any change, and for large DOM trees, this requires traversing the tree as you alluded to. If you wrap the paragraphs in a component and/or the form in a component, it will allow LiveV…

Alright then, I guess I’m gonna go write a couple of components and see what impact it has on the performance.

Would love to hear back if this actually solved your issue

Changing the messages, the p tags, to components gave me a definite improvement on that front. Not seeing 500ms times any more, though still getting a lot of 100ms+ layout reflows. I’ve removed anything that isn’t structural from the following template, but this is what the base LiveView component …

[image] chrismccord: Components would solve your issues in this case. The issue is we have to patch the entire LiveView DOM container for any change, and for large DOM trees, this requires traversing the tree as you alluded to. If you wrap the paragraphs in a component and/or the form in a compo…

As a followup for anyone looking about performance information, my biggest issue after changing to the live components was a continued reflow being forced on the client whenever I was appending a new message to the screen. This is 100% due to having scrolling enabled in the browser. Whatever LiveVi…

LiveView append and performance degradation with large number of appended elements

Questions & Help Questions

Exadra37 December 15, 2020, 8:43pm 31

Would not make sense to open an issue in Github for this?

Or maybe notify(via forum) Chris McCord for this performance issues?