Case with many plain elements

[wclr]

I have say array of words with about 2500 items that I want to output at once, so I do:

      div(words
        .map(word => span(`.word-wrap.${cls(word)}`,
          {attributes: {'data-index': word.index}},
          word.text + ' ')
        )
      )

It takes about 10 sec on my machine to appear on the screen Also here cls(word) is dynamic class maker for each word, it determines if the word is selected and puts selected class. So each time selected word is changed diff algorithm is working I believe - and it too takes a few seconds for view to update.

So I decided to try with innerHTML

h('div', {innerHTML: words
        .map(word =>
        `<span class="word-wrap ${cls(word)}" ` +
        `data-index="${word.index}">${word.text}</span>`
        ).join(' ')
      })

First rendering about less than 1 sec and when cls() changes it will redraw all the words, but it agin takes less than 1sec. I understand that innerHTML is quick there is not any diff ectc, and for now it is like a hack to my case, but why vdom here is so slow?

any advice?

[leeoniya]

@whitecolor

huh, vdom diff on 2500 nodes should be pretty cheap. i wrote this up [1] using domvm [2] and on an i5 laptop get 50ms for initial render and 0.5ms 40ms for diff + class updates & redraw in Chrome and Firefox. domvm also does a full vtree rebuild and diff, which i believe is similar to virtual-dom.

EDIT Sorry, 40ms for diff & patch, forgot to switch off requestAnimationFrame debouncing so timer doesnt lie :) Link updated.

[1] https://jsfiddle.net/f5r2wvf1/1/ (see console) [2] https://github.com/leeoniya/domvm

[wclr]

The problem I believe not in diff but that it renders 2500 elements about 10 sec on the page.

import {h} from 'virtual-dom'

let words = Array.apply(null, Array(2500))
  .map((x, index) => ({text: 'word' + index, index}))
const cls = () => '.selected'

function render() => {
  return h('div', {},
    words.map(word => h('span' + cls(word),
      {attributes: {'data-index': word.index}},
      word.text
      )
    )
  )
}

var start = new Date()

var tree = render();              
var rootNode = createElement(tree);    
document.body.appendChild(rootNode);

console.log('DONE', new Date() - start, 'ms') // 10sec

Is it expected to be so pretty slowo in this case?

@leeoniya is domvm alternative to vdom? have you tried the same with virtual-dom?

[leeoniya]

@whitecolor

Is it expected to be so pretty slowo in this case?

it's almost certainly a bug, since other vdom libs can render and redraw everything in 50ms or even less if you use a lower-level lib like citojs, kivi, Inferno, preact. 10s cannot possibly be expected behavior, i see nothing in your code that should be causing this.

is domvm alternative to vdom?

it is one of many alternatives. i wrote it after using Mithril and domchanger, so it has useful similarities to those libs but imo much better ergonomics and is significantly faster than the majority of other libs with concise, pure-js template syntax...if you're into that sort of thing.

have you tried the same with virtual-dom?

i have not used virtual-dom in a long time. i did evaluate it a couple years ago but ended up with Mithril back then due to speed, size and the higher-level usability.

[wclr]

@leeoniya what do you think about snabbdome?

[leeoniya]

@whitecolor snabbdom looks excellent if you just need a raw vdom lib that's pleasant to use. I think it squarely replaces virtual-dom and is absurdly tiny to boot. I wrote up the 2500 span test [1] and got 35ms/35ms. I will do a more through comparison in a domvm discussion issue and tag you as this is out of scope for this bug.

UPDATE: looked into the perf discrepancy in domvm, now has performance better than snabbdom:

render: 32.921ms redraw: 18.729ms

[1] https://jsbin.com/puvowiyutu/1/edit?js

[jamesamcl]

I have similar performance issues with hyperscript and a large table of elements. After some profiling I'm pretty sure it's nothing to do with diff/patch - rather, it's due to the large amount of garbage generated when rendering a large virtual DOM tree.

[wclr]

any thoughts how can be imroved?