<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                合規國際互聯網加速 OSASE為企業客戶提供高速穩定SD-WAN國際加速解決方案。 廣告
                ## Chapter 9. General Programming(通用程序設計) ### Item 67: Optimize judiciously(明智地進行優化) There are three aphorisms concerning optimization that everyone should know: 有三條關于優化的格言是每個人都應該知道的: More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason—including blind stupidity. 比起其他任何單一的原因(包括盲目的愚蠢),很多計算上的過失都被歸昝于效率(不一定能實現)。 —William A. Wulf [Wulf72] We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. 不要去計較效率上的一些小小的得失,在 97% 的情況下,不成熟的優化才是一切問題的根源。 —Donald E. Knuth [Knuth74] We follow two rules in the matter of optimization: Rule 1. Don’t do it. Rule 2 (for experts only). Don’t do it yet—that is, not until you have a perfectly clear and unoptimized solution. 在優化方面,我們應該遵守兩條規則: 規則 1:不要進行優化。 規則 2 (僅針對專家):還是不要進行優化,也就是說,在你還沒有絕對清晰的未優化方案之前,請不要進行優化。 —M. A. Jackson [Jackson75] All of these aphorisms predate the Java programming language by two decades. They tell a deep truth about optimization: it is easy to do more harm than good, especially if you optimize prematurely. In the process, you may produce software that is neither fast nor correct and cannot easily be fixed. 所有這些格言都比 Java 編程語言早了 20 年。它們告訴我們關于優化的一個深刻的事實:很容易弊大于利,尤其是如果過早地進行優化。在此過程中,你可能會生成既不快速也不正確且無法輕松修復的軟件。 Don’t sacrifice sound architectural principles for performance. Strive to write **good programs rather than fast ones.** If a good program is not fast enough, its architecture will allow it to be optimized. Good programs embody the principle of information hiding: where possible, they localize design decisions within individual components, so individual decisions can be changed without affecting the remainder of the system (Item 15). 不要為了性能而犧牲合理的架構。努力編寫 **好的程序,而不是快速的程序。** 如果一個好的程序不夠快,它的架構將允許它被優化。好的程序體現了信息隱藏的原則:在可能的情況下,它們在單個組件中本地化設計決策,因此可以在不影響系統其余部分的情況下更改單個決策([Item-15](/Chapter-4/Chapter-4-Item-15-Minimize-the-accessibility-of-classes-and-members.md))。 This does not mean that you can ignore performance concerns until your program is complete. Implementation problems can be fixed by later optimization, but pervasive architectural flaws that limit performance can be impossible to fix without rewriting the system. Changing a fundamental facet of your design after the fact can result in an ill-structured system that is difficult to maintain and evolve. Therefore you must think about performance during the design process. 這并不意味著在程序完成之前可以忽略性能問題。實現上的問題可以通過以后的優化來解決,但是對于架構缺陷,如果不重寫系統,就不可能解決限制性能的問題。在系統完成之后再改變設計的某個基本方面可能導致結構不良的系統難以維護和進化。因此,你必須在設計過程中考慮性能。 **Strive to avoid design decisions that limit performance.** The components of a design that are most difficult to change after the fact are those specifying interactions between components and with the outside world. Chief among these design components are APIs, wire-level protocols, and persistent data formats. Not only are these design components difficult or impossible to change after the fact, but all of them can place significant limitations on the performance that a system can ever achieve. **盡量避免限制性能的設計決策。** 設計中最難以更改的組件是那些指定組件之間以及與外部世界的交互的組件。這些設計組件中最主要的是 API、線路層協議和持久數據格式。這些設計組件不僅難以或不可能在事后更改,而且所有這些組件都可能對系統能夠達到的性能造成重大限制。 **Consider the performance consequences of your API design decisions.** Making a public type mutable may require a lot of needless defensive copying (Item 50). Similarly, using inheritance in a public class where composition would have been appropriate ties the class forever to its superclass, which can place artificial limits on the performance of the subclass (Item 18). As a final example, using an implementation type rather than an interface in an API ties you to a specific implementation, even though faster implementations may be written in the future (Item 64). **考慮API設計決策的性能結果。** 使公共類型轉化為可變,可能需要大量不必要的防御性復制([Item-50](/Chapter-8/Chapter-8-Item-50-Make-defensive-copies-when-needed.md))。類似地,在一個公共類中使用繼承(在這個類中組合將是合適的)將該類永遠綁定到它的超類,這會人為地限制子類的性能([Item-18](/Chapter-4/Chapter-4-Item-18-Favor-composition-over-inheritance.md))。最后一個例子是,在 API 中使用實現類而不是接口將你綁定到特定的實現,即使將來可能會編寫更快的實現也無法使用([Item-64](/Chapter-9/Chapter-9-Item-64-Refer-to-objects-by-their-interfaces.md))。 The effects of API design on performance are very real. Consider the getSize method in the java.awt.Component class. The decision that this performance-critical method was to return a Dimension instance, coupled with the decision that Dimension instances are mutable, forces any implementation of this method to allocate a new Dimension instance on every invocation. Even though allocating small objects is inexpensive on a modern VM, allocating millions of objects needlessly can do real harm to performance. API 設計對性能的影響是非常實際的。考慮 `java.awt.Component` 中的 getSize 方法。該性能很關鍵方法返回 Dimension 實例的決定,加上維度實例是可變的決定,強制該方法的任何實現在每次調用時分配一個新的 Dimension 實例。盡管在現代 VM 上分配小對象并不昂貴,但不必要地分配數百萬個對象也會對性能造成實際損害。 Several API design alternatives existed. Ideally, Dimension should have been immutable (Item 17); alternatively, getSize could have been replaced by two methods returning the individual primitive components of a Dimension object. In fact, two such methods were added to Component in Java 2 for performance reasons. Preexisting client code, however, still uses the getSize method and still suffers the performance consequences of the original API design decisions. 存在幾種 API 設計替代方案。理想情況下,Dimension 應該是不可變的([Item-17](/Chapter-4/Chapter-4-Item-17-Minimize-mutability.md));或者,getSize 可以被返回 Dimension 對象的原始組件的兩個方法所替代。事實上,出于性能原因,在 Java 2 的組件中添加了兩個這樣的方法。然而,現有的客戶端代碼仍然使用 getSize 方法,并且仍然受到原始 API 設計決策的性能影響。 Luckily, it is generally the case that good API design is consistent with good performance. **It is a very bad idea to warp an API to achieve good performance.** The performance issue that caused you to warp the API may go away in a future release of the platform or other underlying software, but the warped API and the support headaches that come with it will be with you forever. 幸運的是,通常情況下,好的 API 設計與好的性能是一致的。**為了獲得良好的性能而改變 API 是一個非常糟糕的想法。** 導致你改變 API 的性能問題,可能在平臺或其他底層軟件的未來版本中消失,但是改變的 API 和隨之而來的問題將永遠伴隨著你。 Once you’ve carefully designed your program and produced a clear, concise, and well-structured implementation, then it may be time to consider optimization, assuming you’re not already satisfied with the performance of the program. 一旦你仔細地設計了你的程序,成了一個清晰、簡潔、結構良好的實現,那么可能是時候考慮優化了,假設此時你還不滿意程序的性能。 Recall that Jackson’s two rules of optimization were “Don’t do it,” and “(for experts only). Don’t do it yet.” He could have added one more: **measure performance before and after each attempted optimization.** You may be surprised by what you find. Often, attempted optimizations have no measurable effect on performance; sometimes, they make it worse. The main reason is that it’s difficult to guess where your program is spending its time. The part of the program that you think is slow may not be at fault, in which case you’d be wasting your time trying to optimize it. Common wisdom says that programs spend 90 percent of their time in 10 percent of their code. 記得 Jackson 的兩條優化規則是「不要做」和「(只針對專家)」。先別這么做。他本可以再加一個:**在每次嘗試優化之前和之后測量性能。** 你可能會對你的發現感到驚訝。通常,試圖做的優化通常對于性能并沒有明顯的影響;有時候,還讓事情變得更糟。主要原因是很難猜測程序將時間花費在哪里。程序中你認為很慢的部分可能并沒有問題,在這種情況下,你是在浪費時間來優化它。一般認為,程序將 90% 的時間花費在了 10% 的代碼上。 Profiling tools can help you decide where to focus your optimization efforts. These tools give you runtime information, such as roughly how much time each method is consuming and how many times it is invoked. In addition to focusing your tuning efforts, this can alert you to the need for algorithmic changes. If a quadratic (or worse) algorithm lurks inside your program, no amount of tuning will fix the problem. You must replace the algorithm with one that is more efficient. The more code in the system, the more important it is to use a profiler. It’s like looking for a needle in a haystack: the bigger the haystack, the more useful it is to have a metal detector. Another tool that deserves special mention is jmh, which is not a profiler but a microbenchmarking framework that provides unparalleled visibility into the detailed performance of Java code [JMH]. 分析工具可以幫助你決定將優化工作的重點放在哪里。這些工具提供了運行時信息,比如每個方法大約花費多少時間以及調用了多少次。除了關注你的調優工作之外,這還可以提醒你是否需要改變算法。如果程序中潛伏著平方級(或更差)的算法,那么再多的調優也無法解決這個問題。你必須用一個更有效的算法來代替這個算法。系統中的代碼越多,使用分析器就越重要。這就像大海撈針:大海越大,金屬探測器就越有用。另一個值得特別提及的工具是 jmh,它不是一個分析器,而是一個微基準測試框架,提供了對 Java 代碼性能無與倫比的預測性。 The need to measure the effects of attempted optimization is even greater in Java than in more traditional languages such as C and C++, because Java has a weaker performance model: The relative cost of the various primitive operations is less well defined. The “abstraction gap” between what the programmer writes and what the CPU executes is greater, which makes it even more difficult to reliably predict the performance consequences of optimizations. There are plenty of performance myths floating around that turn out to be half-truths or outright lies. 與 C 和 C++ 等更傳統的語言相比,Java 甚至更需要度量嘗試優化的效果,因為 Java 的性能模型更弱:各種基本操作的相對成本沒有得到很好的定義。程序員編寫的內容和 CPU 執行的內容之間的「抽象鴻溝」更大,這使得可靠地預測優化的性能結果變得更加困難。有很多關于性能的傳說流傳開來,但最終被證明是半真半假或徹頭徹尾的謊言。 Not only is Java’s performance model ill-defined, but it varies from implementation to implementation, from release to release, and from processor to processor. If you will be running your program on multiple implementations or multiple hardware platforms, it is important that you measure the effects of your optimization on each. Occasionally you may be forced to make trade-offs between performance on different implementations or hardware platforms. Java 的性能模型不僅定義不清,而且在不同的實現、不同的發布版本、不同的處理器之間都有所不同。如果你要在多個實現或多個硬件平臺上運行程序,那么度量優化對每個平臺的效果是很重要的。有時候,你可能會被迫在不同實現或硬件平臺上的性能之間進行權衡。 In the nearly two decades since this item was first written, every component of the Java software stack has grown in complexity, from processors to VMs to libraries, and the variety of hardware on which Java runs has grown immensely. All of this has combined to make the performance of Java programs even less predictable now than it was in 2001, with a corresponding increase in the need to measure it. 自本條目首次編寫以來的近 20 年里,Java 軟件棧的每個組件都變得越來越復雜,從處理器到 vm 再到庫,Java 運行的各種硬件都有了極大的增長。所有這些加在一起,使得 Java 程序的性能比 2001 年更難以預測,而對它進行度量的需求也相應增加。 To summarize, do not strive to write fast programs—strive to write good ones; speed will follow. But do think about performance while you’re designing systems, especially while you’re designing APIs, wire-level protocols, and persistent data formats. When you’ve finished building the system, measure its performance. If it’s fast enough, you’re done. If not, locate the source of the problem with the aid of a profiler and go to work optimizing the relevant parts of the system. The first step is to examine your choice of algorithms: no amount of low-level optimization can make up for a poor choice of algorithm. Repeat this process as necessary, measuring the performance after every change, until you’re satisfied. 總而言之,不要努力寫快的程序,要努力寫好程序;速度自然會提高。但是在設計系統時一定要考慮性能,特別是在設計API、線路層協議和持久數據格式時。當你完成了系統的構建之后,請度量它的性能。如果足夠快,就完成了。如果沒有,利用分析器找到問題的根源,并對系統的相關部分進行優化。第一步是檢查算法的選擇:再多的底層優化也不能彌補算法選擇的不足。根據需要重復這個過程,在每次更改之后測量性能,直到你滿意為止。 --- **[Back to contents of the chapter(返回章節目錄)](/Chapter-9/Chapter-9-Introduction.md)** - **Previous Item(上一條目):[Item 66: Use native methods judiciously(明智地使用本地方法)](/Chapter-9/Chapter-9-Item-66-Use-native-methods-judiciously.md)** - **Next Item(下一條目):[Item 68: Adhere to generally accepted naming conventions(遵守被廣泛認可的命名約定)](/Chapter-9/Chapter-9-Item-68-Adhere-to-generally-accepted-naming-conventions.md)**
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看