I've investigated roughly. I've focused on only the use case of passing a single arg. A case of passing multiple args is out of scope here.

Since `append` can take multiple args, Blink always allocates a HeapVector for holding multiple args, even if a single div is passed actually, which can be a reason for the noticeable difference.

As an experiment, I've made other versions of |append|, A) |appendSingleNode| and B) |appendSingleNodeOrString| for comparison. Both can take only single parameter. See https://chromium-review.googlesource.com/c/chromium/src/+/927928

The benchmark result is:

https://jsperf.com/appendchild-vs-append2

- appendChild:              5,227 Ops/sec
- append:                   4,313 Ops/sec
- appendSingleNode:         5,448 Ops/sec
- appendSingleNodeOrString: 5,104 Ops/sec

The benchmark result is not stable, however, I can say append is always slowest in every runs.

Binding folks, if you have any ideas to avoid allocating HeapVector for a single arg, let us know that.

It probably wouldn't be too hard to map to a HeapVector with inline capacity (whatever we think is reasonable; maybe 4 or 8?).

Depending on what the call sites do, it might also be useful to make efficient move-constructing from a vector of different inline capacity possible.

Not clear to me whether append and other varargs IDL methods have substantial usage (after all, callers can already use appendChild).

> Not clear to me whether append and other varargs IDL methods have substantial usage (after all, callers can already use appendChild).

I'm not sure about each usage, however, this is a general issue of varagrs IDL methods, as you said.

Maybe we might want to change the title of this issue, or file a new issue so that people know that this might apply other varargs IDL methods widely.

I think the difference can be detected only by micro benchmarks.
It is unlikely that real web sites can notice the difference.

This is P3 issue for us, I think.