-
So far we have discussed functionality in debuggers that allow you to fix codeand make sure it is working as you would expect it to. Sometimes however, gettingthe code to work is the easy bit—making it fast is often far harder. We are still on thesubject of debuggers but now rather than inspecting to make sure each part of thecode is working, we instead need to record the entire process so that we can spotpatterns in performance (looking at the overall running of the code rather than eachinpidual function/line).36553
- 上一篇：智能冲压工艺规划系统英文文献和中文翻译
- 下一篇：六自由度电阻机器人英文文献和中文翻译
This is a subject that could easily fill an entire book, so Iwill go over the basics and it should give you a good starting point for figuring outhow to understand and improve the performance.In Chrome, the tool that we use to measure performance of the code is thetimeline. I should note that the network pane is also related, as it lets us see whichresources are causing a delay. But I’m going to focus on the running of the coderather than the resources, because it is more likely that you have experience withresources (on a normal website) than with performance testing of the code (crucial forthe more creative of web apps).To start using the timeline, you need to record the running of the code by clickingthe circle button. As soon as it starts recording you will notice that some graphs arecreated. There are (at the time of writing) three aspects that are recorded: Events,Frames, and Memory; all these are recorded simultaneously but can only be viewedseparately by selecting them. At the basic level, these features give you a good way totest the speed of parts of your code because it breaks down the code like a stack,showing you each function call. This is a fairly easy way to find bottlenecks, but itonly really scratches the surface of what the timeline can do.Rather than just showing the amount of time the function takes, it also splits itinto loading, scripting, rendering, and painting. These are extremely useful forknowing why a function is taking longer than it should.
The loading category is whereany XHR (AJAX) calls are made as well as parsing the HTML. The logic within thefunction is included in the scripting category. Rendering is where the DOMmanipulation takes place, primarily recalculating styles and layout. Paint is where thebrowser updates what is being shown to match the outcome of the rendering,including any changes on canvas and other elements that are not directly DOM related.In Chapter 2, we use canvas for a simulation of birds flocking (known as Boids) andso I have recorded that using the timeline to show you how it works. Figure 1 showsthe events timeline, useful for timing functions and visually seeing the stack that theyproduce. There are only two different colors shown in the screenshots. This is becausethere are very few DOM elements due to using a canvas and so there is no loadingand rendering required. The lack of DOM is also the same reason for the patternswithin the timeline, if we were recording performance of a regular website,then wemight see changes on scrolling or hovering over a button; so the timeline is definitely powerful for more than canvas animations! Figure 2 shows the frames timeline. Thismeasures the Frames Per Second (FPS) of the pageBecause a low FPS can make a site or animation look “janky” instead of thesmooth experience that people expect. The third screenshot of this section, Figure 1-4,shows the memory timeline; you can see from the spikes that the memory stores moreand more until the garbage collector comes along and clears the memory that isstoring old data. You will notice that there is quite a lot of whitespace below thetimeline. This space is for a graph showing the amount of DOM nodes and eventhandlers (as you can see in Figure 1-5, which shows the timeline for a basic portfoliowebsite I once made).
时间表到目前为止我们已经讨论了在调试器允许你修改代码， 确保它的工作是你希望的功能。然而有时，得到编码工作是比较容易的使其快速往往是很难的。我们仍然对调试器的主题但现在而不是检查以确保代码的每一部分的工作， 我们需要记录整个过程，我们可以发现模式的性能（看代码的整体运行而不是单个的功能/线）。这是一个主题，可以写一整本书，所以我会在基础，它应该给你一个很好的起点，如何理解和提高性能。在Chrome中，我们使用的代码的性能测量工具是时间。我应该注意到，网络窗格也相关，因为它让我们看到资源造成的延迟。但我要专注于代码的运行而不是资源，因为它更有可能的是，你有经验和资源（在正常的网站）比代码的性能测试（为更具创造性的Web 应用程序的关键）。论文网