Optimizing h

Continuing from #182 and focusing on h.

h is in charge of returning a new vnode. Currently it exposes 2 additional features if I may say:

1. It handles splats (varargs) of children.
2. It concatenates contiguous string and number children into one text node.

Both features have a performance impact.

Splats

It’s basically here to support how some jsx transformers work. My feeling is they do it this way because it makes parsing/codegen easier for them.

Pros	Cons
• Support all jsx transformers (react-compliant)	• Slow (http://jsperf.com/function-signatures) • More bytes

It has been discussed for the babel jsx transformer a while ago: https://github.com/babel/babel/issues/2034. The babel team didn’t do anything on this, @substack developed his own babel transformer for this specific case: https://github.com/substack/babel-plugin-jsx-factory.

We could either simply drop splats support and align with a clean vdom function signature. This would involve changing of babel transformer and investigate if webpack transformer supports this.

Or we could, as a mentioned here wrap h in a hjsx function that just handle splats, for those who really want to use it.

Concatenation

It concatenates string and number children into one text node.

Pros	Cons
• Less nodes to diff	• Additional memory • Additional processing • More bytes

It feels that having so many string/number contiguous nodes that there is a real performance benefit to merge them is less than obvious. Still, it allocates a stack and process it for each h call which has a non-negligible performance impact and gc stress.

EDIT: I’m talking about the internal stack here. I wrongly believed it was needed for concatenation, but it’s in fact because of how hyperx make calls to h. So everything here applies to ‘hyperx’ nested children handling instead of concatenation.

My advice on this would be to simply drop it and compare hyperapp diff benchs before and after.

Related

• https://github.com/hyperapp/hyperapp/pull/184
• https://github.com/hyperapp/hyperapp/issues/185

[jorgebucaran]

I was able to get it down to this:

export default function (tag, data) {
  var children = []

  for (var i = 2; i < arguments.length;) {
    push(arguments[i++], children)
  }

  return typeof tag === "string"
    ? {
      tag: tag,
      data: data || {},
      children: children
    }
    : tag(data, children)

  function push(node) {
    if (Array.isArray(node)) {
      for (var i = 0; i < node.length; i++) {
        push(node[i], children)
      }
    } else if (node != null && node !== true && node !== false) {
      children.push(node)
    }
  }
}

but there was no perf advantage and not a big byte difference.

[selfup]

Also for performance using switch over if else if else can be a an easy win

As well as if (something === undefined) over if (!something) which will give a 15% improvement