Fix test cases.

[jridgewell]

First, regions have a pointer to its el. No need for a lookup. Second, I'm
detaching all contents before running the replaces. Third, never replace
top view's el, just modify.

[jridgewell]

With these changes:

Test 2

• DOM ops: 10001
  Total time: 664.9459999753162
• DOM ops: 10001
  Total time: 633.075000019744
• DOM ops: 10001
  Total time: 658.1039999146014

Test 3

• DOM ops: 2
  Total time: 608.6029999423772
• DOM ops: 2
  Total time: 755.5380000267178
• DOM ops: 2
  Total time: 669.0780000062659

[jamesplease]

I think we want the clone to deeply clone data and events, right?

[jridgewell]

Correct, let me update.

[jridgewell]

Actually, it defaults to the value of withDataAndEvents. 😃

[jamesplease]

Oh, would ya look at that!

[jamesplease]

Looking good, looking good. Just one Q, and I'll merge it in!

[jridgewell]

Additionally, I was able to kick both test's asses using the same kind of placeholder that I used in regions. It's in test 4.

Test 4

• DOM ops: 10004
  Total time: 420.87700008414686
• DOM ops: 10004
  Total time: 389.65000002644956
• DOM ops: 10004
  Total time: 406.3959999475628

[jamesplease]

Everything I've read suggests to me that there's got to be some test case we can find where the 10k+ DOM op methods will be incredibly slow...maybe mobile?

There's no way people would talk so much about slow reflows if these DOM operations were so quick.

...right?

[jridgewell]

I thought so too. I read http://korynunn.wordpress.com/2013/03/19/the-dom-isnt-slow-you-are/, and while it's a bit aggressive, it brings up one very good point:

Really? You don’t think it can be as fast? You think that your proficiency as a developer outstrips the devs working under the hood of chrome? firefox?

I think if you incrementally add/remove/replace like the original test 2 was doing, you're gonna have a slow time. But the DOM is fast, it's just not object property access fast.

[jamesplease]

I should clarify...whenever I refer to DOM ops, I really mean the ones that affect nodes that are children of the document. In other words, the ones that I'm counting in these tests.

I expect that the DOM, when detached, will function performance-wise on the same order of magnitude as VDom. The whole point of VDom, as I understand it, is to reduce the # of those DOM ops that could cause reflows. Yet these tests seem to be showing that my thinking on this may simply be completely wrong :)

I was also thinking that your tests would show an empty list for some time, but, it seems they're blinking exactly the same.

[jamesplease]

Checking out this article, I'm wondering if this may have something to do with it:

This means that if the changes happen quickly enough in the same thread, they may only produce one reflow. However, this cannot be relied on, especially considering the various different speeds of devices that Opera runs on.

It's probably worthwhile to test these on various devices, too.

[jridgewell]

Probably. I don't think a reflow can happen until the event loop moves on?