search

wilsonpage / fastdom

Eliminates layout thrashing by batching DOM measurement and mutation tasks
6.83k stars 240 forks source link

Read/write barriers? #21

Closed indutny closed 10 years ago

indutny commented 10 years ago

Not sure if its really needed, but just for consistency with CPUs and for APIs sake having read/write barriers might sound like a good idea.

wilsonpage commented 10 years ago

I don't understand, can you give an example?

indutny commented 10 years ago

Sure, basically I meant concept similar to this: http://en.wikipedia.org/wiki/Memory_barrier .

In FastDOM you're reordering reads and writes to make performance optimal just as CPU does it with read/write instructions, but sometimes you may want to be sure that all previous writes/reads are completed before doing next read/write. Its like flush, but it isn't necessary to do flush immediately, its just about having some sort of dependencies between read/write ops.

wilsonpage commented 10 years ago

Ahhh ok, I think I get it. But because we use requestAnimationFrame I don't think there will be a chance that frame callbacks will overlap. I could be wrong, but maybe you write a test to prove this is an issue?

indutny commented 10 years ago

You're right if the sequence of read writes is happening in different frames, but if all that read writes are happening in one frame - you might wish to have some restrictions on order of read/writes to make them observe each other changes. That's where barriers come to help.

Anyway, this is just an idea and not a real bug, or something that bothers me. So please feel free to ignore it if it doesn't seem to be useful for anyone else.

wilsonpage commented 10 years ago

Cheers guys, I'm going to close this for now :)