Mootools的removeClass在IE上非常慢
我在 mooTools 中的同一组元素上应用 addClass 和removeClass。addClass 工作正常,但removeClass 花费的时间太长,大约 6-7 秒。请参阅下面的代码。
$('usermailbox').getElements('input[class=emailmessages]').each(function(el){
el.getParents().addClass('unChecked');//works fine
});
$('usermailbox').getElements('input[class=emailmessages]').each(function(el){
el.getParents().removeClass('selected'); //Takes too long in IE
});
我还有希望吗?
I am applying addClass and removeClass on same set of elements in mooTools.addClass works fine but removeClass takes too long approx 6-7sec.Please see the code undeneath.
$('usermailbox').getElements('input[class=emailmessages]').each(function(el){
el.getParents().addClass('unChecked');//works fine
});
$('usermailbox').getElements('input[class=emailmessages]').each(function(el){
el.getParents().removeClass('selected'); //Takes too long in IE
});
Do I have any hope ?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
正确的。这里有几个问题...显然,在没有看到 DOM 的情况下很难确定,但是:
您执行相同的操作两次。在同一个实例中,您可以添加类和删除类
,
执行
element.getElements("input[class=emailmessages]")
与element.getElements("input.emailmessages")
可能会慢一些,但可能会返回包含您可能不想要的其他类的输入。el.getParents() 将返回所有父母。然后你再次迭代它们。两次。你确定你的意思不仅仅是
.getParent()
,单数吗?如果是这样,或者只有一个父元素,则您将在单个元素上应用 .each,这是不必要的命中。如果您的逻辑需要保留,则将其视为单个迭代:
存储和行走。
总而言之:
当然,使用 Slick / mootools 1.3,您可以做得更简单:
在这个 dom 上:
以下内容将返回所有 div:
当然,您可以只执行
$("useremail")。 getElements("div.selected,div.unChecked")
无论如何都可以随时访问这些 div....所以这一切都取决于你的 DOM 和需求,你所做的事情一定有一个原因是 正在做。性能的底线:
将查找结果缓存到变量中。如果您调用
$("someid")
两次,请将其缓存在您的作用域中。如果你执行$("someid").getElements()
两次,那么性能会差两倍以上......并且添加.getParents()
两次,那就是。 ..现在糟糕了n倍...避免将 chaqined 方法应用于这样的集合:
collection.addClass("foo").removeClass("bar")
- 它将迭代它两次或n次,去对于单个.each
回调,速度会快得多。如果可能的话,尽量避免反向组合器或父级查找,直接进行。您可以使用
nth-child
等 - 除了到达输入并返回之外,还可以使用其他方式来遍历 DOM。特别是当您实际上并不需要输入本身时....getParents(selector)
将限制您想要的父项类型。.getParents()
将返回负载,一直到父/锚 dom 节点,通常包括与兄弟节点相同的负载。始终使用匿名函数创建本地作用域,这样就不会污染全局对象或上层作用域 - IE 不喜欢这样,并且会使访问变量变慢。
希望其中一些是有道理的,至少:)祝你好运并记住,速度只是相对的,并且与你支持的最慢浏览器中的性能一样好。
Right. Several issues here... Obviously, w/o seeing the DOM it is a little difficult to determine but:
you do the same operations twice. in the same instance you can addClass and removeClass
doing
element.getElements("input[class=emailmessages]")
vselement.getElements("input.emailmessages")
is probably slower but may return inputs that have other classes as well that you may not want.el.getParents() will return all parents. you then iterate them again. twice. are you sure you don't mean just
.getParent()
, singular? if so, or if its one parent only, you are applying a .each on a single element, which is an unnecessary hit.if your logic needs to remain then consider this as a single iteration:
store and walk.
all in all:
of course, with Slick / mootools 1.3 you can do it a lot more simple:
on this dom:
the following will return all the divs:
of course, you can just do
$("useremail").getElements("div.selected,div.unChecked")
to get to these divs at any time anyway.... so it all depends on your DOM and needs, there must be a reason why you are doing what you are doing.bottom line for perf:
cache results of lookups into vars. if you call
$("someid")
twice, cache it in your scope. if you do$("someid").getElements()
twice, that's more than twice as bad in performance... and add.getParents()
twice, thats ... n-times as bad now...avoid applying chaqined methods to collections like this:
collection.addClass("foo").removeClass("bar")
- it will iterate it twice or n-times, go for a single.each
callback instead, it will be much faster.try to avoid reverse combinators or parents lookups if possible, go direct. you can use
nth-child
etc - other ways to walk your DOM than to get to the input and walk back. Especially when you don't really need the input itself....getParents(selector)
will limit the types of parents you want..getParents()
will return buckloads, all the way up the parent / anchor dom node, often including the same ones for siblings.always create a local scope with anonymous functions so you don't pollute your global object or upper scopes - IE does not like that and makes accessing variables slow.
Hope some of this makes sense, at least :) good luck and remember, speed is only relative and is as good as your performance in the slowest browser you support.