@Mark Hmm... I'm not 100% sure I understand. Afaik using lazy in the rendering is mostly used to avoid building the "virtual dom tree" unnecessarily. What I'm mostly concerned about is that it seems the virtual dom library is rendering (i.e. the browser is issuing draw commands) the full tree, even if they are identical (or all but one leaf-node in the tree). Although, I think I saw that the view function is called even if I use lazy, but that has less impact on the performance loss I'm seeing (which mostly manifest itself in the "rendering block" shown in the profiling flame chart).
Anyway, I think I need to write a "pure" js/html version to have something to compare with. But I don't have too much time to look into this now, so I don't think I will be able to do this any time soon. I'll get back to this thread when I will have had more time to look into this. However, if anyone think it is worth creating a github issue on related project from the information that have been gathered so far. Let me know. Thanks everyone for pitching in! On Sunday, February 12, 2017 at 4:12:16 AM UTC+9, Mark Hamburg wrote: > > How are you passing your model to the rendering function in Html.Lazy > without it triggering on other changes to the model? Does Html.Lazy not > look for changes in the function itself and you just use a closure to pass > the actual model value? That would seem like a bug in Html.Lazy if it did > so though you would be making it a useful bug. > > More technically, as with any other function, the results of Html.Lazy > functions can (or at least should) only depend on their inputs. Lazy nodes > in the rendering graph reuse the previous rendering if their inputs haven't > changed (based on a shallow comparison) and otherwise re-render. You need > to pass the model to the lazy node in order to have something to render and > if the model is experiencing shallow changes — e.g., because a non-change > may still rebuild parts of the model — that should result in re-rendering. > > Mark > > P.S. I do wonder whether it would be useful to have a deep lazy equivalent > that would perform a deeper comparison to see whether it could avoid > re-rendering. As with the existing lazy implementation, it wouldn't need to > be "perfect" — for example functions might only be subject to shallow > comparisons — but looking more deeply into the inputs would allow for more > rendering patterns in which a collection of parameters are collected into a > record that might get rebuilt on every rendering pass. > > On Feb 8, 2017, at 8:01 AM, 'Rupert Smith' via Elm Discuss < > elm-d...@googlegroups.com <javascript:>> wrote: > > On Wednesday, February 8, 2017 at 12:43:26 PM UTC, Julian wrote: >> >> Any idea if this is expected behavior? Or is this a bug with the virtual >> dom code? >> > > Have you tried Html.Lazy? It performs an extra check on the model to see > if it has changed (by reference comparison): > > http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html-Lazy > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elm-discuss...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
