我正在致力於simple text markup Java Library，除其他要求外，它應該很快。Java分析 - 它給出的值有多可靠？
爲此，我做了一些分析，但結果給我更糟的數字，然後在非配置文件模式下運行時測量。
所以我的問題是 - 多少可靠的是分析？這是否只給出了在方法中花費的時間的信息比率？這是否考慮到JIT編譯器，還是隻解析分析模式？我使用NetBeans Profiler和Sun JDK 1.6。
謝謝。
當運行分析，你永遠會導致性能下降的東西具有測量開始/停止的方法時，跟蹤堆中的對象（對於內存分析），於是就有了管理開銷。
但是，它會給你清楚的指示，找出瓶頸在哪裏。我傾向於尋找花費最多累計時間的方法，並檢查是否可以進行優化。確定方法是否被不必要地調用也很有用。
使用非常小的方法，只需少量鹽就可以得到剖面結果，有時測量過程比方法調用本身需要更多的時間，並且會導致結果偏斜（可能會出現一個小的，通常稱爲方法有更多的性能影響）。
希望有所幫助。
由於工具分析代碼平均運行速度比未分析代碼慢。然而，測量速度並不是分析的目的。
的剖析輸出將指向你的瓶頸，即線程花費更多時間的地方，代碼，表現差於預期，或可能的內存泄漏。
您可以使用這些提示再次改進所述方法和配置文件，直到您對結果滿意爲止。
一個分析器將不會是一種編碼風格是不是最佳慢X％但是一個解決方案，你仍然需要花時間微調您的代碼，使用頻率高於其他的那些部分。
我並不感到驚訝的是，當您的應用程序分析時得到的結果最差，因爲測試java代碼通常會減慢其執行速度。這實際上是很好的維基百科頁面抓獲Profiling其中提到，儀器儀表可以導致改變程序的性能，有可能導致不準確不準確的結果和heisenbugs（由於the observer effect：觀察家影響他們所觀察，由單純的單獨觀察它的行爲）。
說了這麼多，如果你想測量速度，我認爲你沒有使用正確的工具。 Profiler用於查找應用程序中的瓶頸（爲此，您並不真正關心整體影響）。但是如果你想對你的庫進行基準測試，你應該使用性能測試工具（例如，像JMeter這樣的東西），它可以給你每次通話的平均執行時間。使用正確的工具，您將獲得更好，更可靠的結果。
[分析應該有JIT編譯器沒有影響。然而，插入到應用程序配置文件中的代碼會使方法減慢很多。
Profillers上severall不同型號工作，他們要麼插入代碼，看看有多長和頻率的方法正在運行或他們只是正在執行什麼樣的代碼重複投票採取樣品。
首先會減慢你的代碼相當多，而第二個是不是100％準確，因爲它可能會錯過一些方法調用。
異形碼勢必在大多數先前的評論提到運行速度變慢。我會說，使用分析來衡量你的代碼的各個部分（比如方法）的相對性能。不要使用分析器中的度量值作爲代碼如何執行總體性能的指標（除非您想要最差情況的度量值，在這種情況下，您所擁有的值將被高估）。
我發現我得到取決於我使用的分析器的不同結果。但結果往往是有效的，但對問題的看法不同。在分析CPU使用情況時，我經常做的事情是啓用內存分配分析。這往往給了我不同的CPU結果（因造成內存分析增加的開銷），可以給我一些有用的地方進行優化。