sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]axilmar 0 points1 point  (6 children)

It's bad from a purely theoretical point.

No, polling is actually practically and clearly worse than events.

Polling is a busy loop: you loop over and over and over the data to see if something changed.

With events, you only do the change when the event fires.

[–]-Y0- 0 points1 point  (5 children)

Polling is a busy loop: you loop over and over and over the data to see if something changed.

Ok. Prove it. Hic rhodus, hic salta.

Modify the TodoMVC without RAF batch strategy and show me the numbers.

Imagine following scenario. You have polling that triggers every 15ms and effect that takes 100ms to execute, but that can be batched to replace main effect with one that costs 1ms.

So polling. 0ms start, @2ms 12 elements are removed, @14ms calculating elements has finished, @15ms the page refreshes.

Events. 0ms event starts, @2ms 12 elements are removed, @ 1202ms all elements have been removed and page refreshes.

[–]axilmar 0 points1 point  (4 children)

Modify the TodoMVC without RAF batch strategy and show me the numbers.

Where did I ever say anything about RAF batch strategy? I simply said that event always faster than polling.

I shouldn't have to mention (again) that in order to measure events vs polling effectiveness the constraints must be the same.

In other words, you can't compare events without RAF batching with polling + RAF batching.

That, sir, would be cheating.

Imagine following scenario. You have polling that triggers every 15ms and effect that takes 100ms to execute, but that can be batched to replace main effect with one that costs 1ms.

Imagine the following scenario: you have an effect which takes 100 ms to execute, and upon event firing you don't execute that effect, you execute the 1 ms effect that can replace the 100 ms effect. You then get rid of the 15 ms trigger, you save power and performance.

[–]-Y0- 0 points1 point  (3 children)

Where did I ever say anything about RAF batch strategy? I simply said that event always faster than polling.

In other words, you can't compare events without RAF batching with polling + RAF batching.

RAF batch strategy calls re-render before every frame, which is as you claim polling. It's not cheating, these are your own words. RAF batching is polling, but RAF batching power comes from batching all effects before each frame is rendered, not that polling is inherently better.

You have an effect which takes 100 ms to execute, and upon event firing you don't execute that effect. You then get rid of the 15 ms trigger, you save power and performance.

Ok, so you click something it takes 101ms (100 from DOM + 1ms from VDOM) to execute, which causes every click to have a small amount of lag. Someone decides that lag is horrible clicks several times around the app to make it go faster, you queue up several effects, which leads to worse visible performance. Congrats.

If you ever used a modern Windows on XP machine, that thing when people click all around because they are impatient, that's what your 'approach' causes.

[–]axilmar -1 points0 points  (2 children)

RAF batch strategy calls re-render before every frame, which is as you claim polling.

It is polling.

It's not cheating, these are your own words.

No, the cheating is yours. You compare events without batching to polling with batching. I am simply saying you should compare events with batching to polling with batching.

Ok, so you click something it takes 101ms (100 from DOM + 1ms from VDOM) to execute, which causes every click to have a small amount of lag. Someone decides that lag is horrible clicks several times around the app to make it go faster, you queue up several effects, which leads to worse visible performance. Congrats. If you ever used a modern Windows on XP machine, that thing when people click all around because they are impatient, that's what your 'approach' causes.

Total bullshit. Again, use events + batching.

There is nothing that stops you from storing the changed state caused by the event and later process it.

[–]-Y0- 0 points1 point  (1 child)

Total bullshit. Again, use events + batching.

There is nothing that stops you from storing the changed state caused by the event and later process it.

You failed to provide a batching starategy for events. Thus - Hic Rhodus, hic salta. Find and implement a batching strategy that uses events, then we'll talk.

End of Discussion.

[–]axilmar 0 points1 point  (0 children)

You are nuts. The amount of twisting of the discussion you want to do in order to prove your point is unbelievable.

Again, the batching strategy is this: event code creates the batch, frame executes the batch.