Lit-html: Performance

[tylergraf]

Hi, you guys are awesome!

Quick question about performance. I've noticed that lit has dropped quite a bit in https://github.com/krausest/js-framework-benchmark between versions 0.7.1 and 0.11.0-dev.1 (rounds 7 and 8 in the results tables). I'm also preparing a presentation for next week talking about performance between polymer, lit, etc. and noticed that it was much slower than polymer 1, 2 and 3. So I pinned back to version 0.6 and it dropped back down in my test of creating and updating 1000 nodes.

Do you know what's making it slower and are the plans to resolve that? Thanks!

round 7 (0.7.1)

round 8 (0.11.0-dev.1)

Just to note:
I'm running on a Galaxy S3. Creating 1000 simple components and updating a single property on every 10 of them.
Polymer 1: ~1500ms
Polymer 2: ~2500ms
Polymer 3: ~2500ms
Lit 0.6: ~2800ms
Lit 0.11.4: ~3800ms

[stramel]

Make sure to check out the latest code perf. They recently reworked a lot on repeats.

https://github.com/Polymer/lit-html/pull/501#issuecomment-425474056

[justinfagnani]

Yeah, is that benchmark using repeat or map? We should really be benchmarking both.

[tylergraf]

@stramel that looks good, thanks.

@justinfagnani I'm not using either. Here's what I'm doing:

for (var i = 0; i < 1000; i++) {
  let el = document.createElement('fs-person');
  el.setAttribute('name',`Tyler ${i}`);
  el.setAttribute('gender','male');
  document.body.appendChild(el);
}
document.querySelectorAll('fs-person').forEach((el,i)=>{
  if(i%10 === 0){
    el.setAttribute('name', `${el.getAttribute('name')} ${i}`);
  }
});

Probably not the best benchmark, but I was able to run it on my native, p1, p2, p3 and lit-element implementations.

[tylergraf]

The one in js-framework-benchmark is using repeat: https://github.com/krausest/js-framework-benchmark/blob/master/frameworks/keyed/lit-html/src/index.js#L173

[CaptainCodeman]

Looks like that is comparing keyed vs non-keyed so isn't a valid comparison.

The next version is dramatically faster with the re-worked repeat which makes for a much more impressive overall score.

[ruphin]

I implemented those benchmarks. The keyed implementation uses repeat, and the non-keyed implementation uses map. I did cheat a bit with the code and added optimisations to avoid as many dynamic assignments as possible, for example by attaching only one global click event handler that catches all the clicks instead of attaching a click handler on each item in the list. It's about as fast as I could get it to run.

I use the same benchmark to compare performance differences between lit-html versions. I haven't tested the latest few releases yet, I will update and report the latest performance changes here.

[CaptainCodeman]

I implemented those benchmarks.

Well, you modified the ones I originally implemented nearly a year ago now :)

The tests have already been updated to the latest release, you can see the results here. I already have some changes to make the updates immutable / use guard which improves the perf of some things (like the select test which seems to be the weakest point compared to some others).

I don't recall lit ever getting slower results than polymer, it's only obvious weak spot was the repeat perf and polymer didn't have support for keyed updates so couldn't be compared directly on that.

Personally, I think it's plenty fast enough - as long as there isn't a big red box like there was before repeat worked properly (now fixed) I think we're good. Yes, better performance is always nice but chasing benchmarks can be a waste of effort better spent on other things and they often don't really reflect real-world usage.

Apologies for the crazy-tall image:

[justinfagnani]

0.12 with the new repeat() implementation looks like it solved the particular regression here. General performance is still a priority (after API stability for 1.0 at least). Going to close this now.