Jquery / Javascript 速度...我真的应该关心吗?
我看过很多文章比较各种选择器查询和 DOM 遍历方法的速度。当然,在具有数百或数千个元素和 O^n 操作的情况下,速度确实很重要,但是在 99% 的 Jquery 响应用户操作而进行一些 DOM 操作(或奇特的动画,或制作吐司)的情况下,速度真的很重要吗?
几乎所有 JQuery 操作不是都会比往返服务器更快吗?
设计超级优化的服务器端代码是有意义的。在 javascript 中负责内存分配和清理是有意义的,这样用户的浏览器就不会像 Flash v5 那样运行。我认为浪费时间优化 JQuery / Javascript 的速度没有任何意义,除非在测试过程中出现明显减慢页面速度的情况。
有人可以告诉我是否以及为什么我应该开始关心 JQuery 速度?
编辑
诚然,我的语气有些发牢骚,但无意争论。当您需要这里,提出我的问题的更好方法是:
次优 Javascript/Jquery 会产生什么影响?
如果我没有注意到,我应该担心吗?
已接受
阅读回复后,我认为这个问题的最佳答案取决于您的项目和团队规模。在程序员没有用户将看到的页面的完整视图的情况下,例如
- 程序员负责页面上的各个功能、
- 程序员独立开发和单元测试
- 的团队,存在定制的前端 API 或其他代码可能会影响实际的响应时间
那么,更加小心并“过早优化”作为常规是有意义的。这在有专门的、专业的前端设计师不做其他事情的情况下是可行的。
在较小的项目上,例如我目前的两人团队:
- 缺乏专业化
- ,需要高程序员输出,
- 将整个前端的责任集中在一个人身上,
所有这些都将优化放在优先级列表上。 @Anurag 的回答帮助我找到了问题的核心并做出了最好的决定。
I've seen lots of posts comparing the speeds of various selector queries and DOM traversal methods. Of course it matters in cases with hundreds or thousands of elements and O^n operations, but does speed really matter in the 99% of cases where Jquery does some DOM manipulation (or whizzy animation, or makes toast) in response to a user action?
Won't almost all JQuery actions be faster than a round-trip to the server?
It makes sense to design uber-optimized server-side code. And it makes sense to be responsible with memory allocation and clean up in javascript so the user's browser doesn't run like Flash circa v5. I don't see any sense in wasting time optimizing the speed of JQuery / Javascript unless something noticeably slows the page down during testing.
Could somebody please tell me if and why I should start caring about JQuery speed?
Edit
My tone is admittedly whiny but not meant to be argumentative. There are good resources on how to approach optimization when you need to here, a better way to ask my question would have been:
What is the impact of sub-optimal Javascript / Jquery?
If I don't notice it, should I worry about it?
Accepted
After reading the responses I think the best answer to this question depends on your project and team size. In situations where programmers don't have a full view of the page the user will see, such as teams where
- programmers are responsible for individual features on a page
- programmers develop and unit test independently
- there is a bespoke front-end API or other code which could impact actual response times
Then it makes sense to be more careful and 'prematurely optimize' as routine. This is feasible in cases where there are specialist, professional front-end designers who do nothing else.
On smaller projects, such as my current two-man team:
- the lack of specialization
- the need for high programmer output
- the concentrated responsibility for the entire front-end in one person
All push optimization down on the priority list. @Anurag's answer helped me get to the core of the question and make the best decision.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
实际上,过早地优化任何东西都是没有意义的,不仅仅是 jQuery。
添加这些微观优化所花费的时间和精力可能不值得。如果某些事情明显缓慢,则深入研究问题,但其他方面则专注于设计好应用程序。
创建良好的应用程序并不容易,过早尝试优化通常会导致设计和架构复杂且难以维护。
Actually it doesn't make sense to optimize anything prematurely, not just jQuery.
The time and effort spent adding those micro optimizations is probably not worth the gains. If something is visibly slow, then dig deeper into the issue, but otherwise focus on designing the application well.
Creating good applications is not an easy, and trying to optimize too early can often lead to convoluted and difficult to maintain designs and architectures.
我实际上想投票赞成结束这个问题,因为主观且有争议性,但我想这并不是要争论。
我们在这里应该问的问题是,为什么我们不应该优化我们的代码?
我不得不承认,ECMA-/Javascript 解释器在过去几年中确实有了很大的改进,因此 Javascript 的整体性能有所提高。然而,浏览器环境中的 Javascript 仍然不是很快。尤其是当涉及到 DOM 操作时,它实际上非常慢(或者:它可能非常慢)。
关于这个主题有很多好书,我强烈推荐的一本是 Nicholas C. Zakas 所著的高性能 Javascript。
举几个我们应该优化代码的原因:
即使使用像 jQuery 这样高度抽象的框架,您也可以轻松地做出可怕的事情。举个例子,像这样的简单查询语句
几乎总是非常慢。问题是,即使这个语句不会明显减慢速度,但如果您没有意识到这一点并且您在没有优化的情况下编写了所有代码,它最终会加起来。
I actually wanted to vote for closing the question as subjective and argumentative, but I guess this isn't about beeing argumentative.
The question we should ask here is, why shouldn't we optimize our code ?
I have to admit, ECMA-/Javascript interpreters did improve like a lot over the last years, so the overall Javascript performance increased. However, Javascript in a browser environment is still not really fast. Especially when it comes to DOM manipulation it's actually pretty slow (or: it can be really slow).
There are numerous great books about this topic, one I highly recommend is High performance Javascript by Nicholas C. Zakas.
To name a few reasons why we should optimize our code are:
Even with a highly abstracted framework like jQuery, you can easily do terrible things. To give on example, a simple query statement like
is almost always terribly slow. The problem is, even this statement wouldn't noticeable slow down things, but if you aren't aware of this and you write all your code without optimizations, it will add up finally.
如果您的代码很慢,jQuery 不太可能成为瓶颈。它的速度很快。
更有可能的是,你的算法出现了问题。
If your code is slow, jQuery won't likely be the bottleneck. It's fast for what it does.
More likely, your algorithm will be the problem.
当它开始变得重要时你应该关心。
也就是说,性能应该是应用程序的特定要求,并且与任何应用程序一样,您不应该花太多时间担心性能,除非性能的缺乏会影响某些要求。当然,我并不是说在有简单的线性替代方案时使用
O(n^3)
算法,但瓶颈可能出现在很多地方,而您选择的 JavaScript 库只是其中之一。You should care when it starts to matter.
That is, performance should be a specific requirement of your applications and, as with any application, you shouldn't spend too much time worrying about performance until the lack thereof impacts some requirement. Of course, I'm not saying use
O(n^3)
algorithms when there is a simple linear alternative but bottlenecks can occur in many places and your JavaScript library of choice is just one of them.jQuery 可帮助您专注于开发,而不是花费大量时间修复跨浏览器不兼容性。速度不是问题,至少对于肉眼来说不是问题。这一切都归结为代码的编写和优化方式。这并不意味着您将停止使用 javaScript,但对于像 ajax 请求这样的任务,使用 jQuery 会让生活变得更轻松,而不必担心跨浏览器不兼容。
更新
阅读下面的评论。
这是我用来测试 javascript 的
for
与 jQuery 的$.each
函数的方法。 jQuery 本地领先 4 毫秒。 jQuery 11 毫秒 vs JavaScript 14 毫秒jQuery helps you focus on your development rather spending hours fixing cross browser incompatibilities. Speed is not an issue, at least not to the naked eye. It all boils down to how your code is written and optimized. It doesn't mean you will stop using javaScript, but for tasks like ajax requests, life is allot easier with jQuery without having to worry about cross browser incompatibilities.
UPDATE
Read comments below.
This is what i used to test the javascript's
for
vs jQuery's$.each
functions. jQuery wins by 4ms locally. jQuery 11ms vs javaScript 14ms