On Fri, May 29, 2009 at 2:59 PM, Daniel F. Kudwien <news@unleashedmind.com> wrote:
Now, you do the math:
10 ms * ~20+ behaviors = 200+ ms
Actually, I was figuring 10ms for LOTS of behaviors. Not PER behavior. A selector should clearly take well under 10ms. Any additional overhead for a behavior is going to be the same regardless of whether you use context or selectors.
There are two patterns in Drupal JS to "prevent" the same behavior from processing the same data twice. One is the :not(processed-X) pattern, which seems to be pretty reliable, and is pretty much entirely in the hands of the author of the behavior (barring a misanthrope who decides to remove your processed classes).
...which equally cannot solve your trivial zebra-striping table row example. Once your table :is(.processed), your behavior can't (shouldn't) process it again.
Oh, come on... you wouldn't drop a zebra stripe processed class on the table, would you? You'd drop it on the row. And if you found rows in a table without striping, you'd re-process the entire table. The problem occurs only when you assume the context is passing sufficient information for your behavior. The context may in fact be providing less information than you need, and you are at the liberty of whatever called attachBehavior() in the first place (which may not be something in core -- there's no way to tell). Consequently, it's better to rely on the document itself, not just the context. Matt -- http://technosophos.com http://querypath.org