停止事件冒泡-能提高性能吗？

Question

如果我在事件回调函数中没有返回false，或者没有使用jQuery的e.stopPropagation特性，那么事件会向上传递到DOM。在大多数情况下，我不关心事件是否冒泡。就像这个DOM结构示例一样：

​<div id="theDiv">
    <form id="theForm" >
        <input type="submit" value="submit"/> 
    </form>
</div>​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

通常情况下，我不会像这样拥有多个嵌套的提交回调函数：

$('#theDiv').submit(function() {
    alert('DIV!');
});
$('#theForm').submit(function(e) {
    alert('FORM!');
    e.preventDefault();
});​

代码片段
这个示例展示了submit事件冒泡到一个<div>上！
如果我停止事件传播或只是阻止默认行为，对我来说没有区别。

在这些情况下，如果我停止事件传播，会获得性能方面的好处吗？

- gdoron is supporting Monica

---

它应该没有任何影响，甚至可能会有所帮助，因为浏览器一直冒泡数百万个事件，它不一定只在有监听器时才冒泡。 - RobG

@RobG。这就是为什么我想取消它的原因... - gdoron

为什么不对其进行基准测试？理论上，停止传播=少做=更快。实际上，这取决于浏览器的实现细节，无论如何都很难注意到差异。 - deceze

Answer 1

性能方面的好处？是的，有一些微小的好处，正如在 这个jQuery live() 和 on() 的性能测试 中所概述的那样。正如@Joseph所指出的那样，两者之间的区别在于live将事件传播到整个树中，而on()只传播到最近的共同父元素。

在这些测试中，显示on()可以比live()快4倍。在实践中，也许仍然不值得一提，但如果你有非常深的html结构和大量的事件触发器，停止传播的性能差异可能是值得的。

- Herman Schaaf

---

实际上，live()现在已经因为这个原因和其他原因而被弃用了。 - hexalys

Answer 2

这里是一个比较on()和live()的区别，涉及冒泡和jQuery替换live()的原因。问题在于live()事件附加到文档上，需要长时间遍历树形结构找到处理器。使用on()可以将处理器附加到最近的公共父级，从而避免长时间查找处理器——这意味着更快的性能。

但我建议您进行自己的基准测试以进行检查。

- Joseph

Answer 3

这个测试显示，尽早终止事件会有性能优势（15%-30%），在复杂的DOM上可能会有更大的差异。有趣的是，无论你在处理事件后做什么，捕获事件监听器似乎比冒泡事件监听器稍快一些。奇怪但有趣；不过我只在一个浏览器中进行了测试。

- Jake