2011-08-30 68 views
9

在工作中,我們正在使用一些非常強大的機器:惠普Z600雙xeon @ 2.5GHz,8-16GB內存。不幸的是,由於公司政策不合適,我們不得不使用32位XP,因此我使用未使用的4GB RAM製作了PAE ramdrive。
現在,臨時文件位於ramdrive上。我也嘗試將整個項目轉移到ramdrive,然後轉移到SSD,但託管模式啓動或編譯時間沒有明顯改善。
我已經運行了SysInternals的進程監視器,看看是否有任何瓶頸與任務管理器/硬盤活動導致不可見,但我沒有看到任何明顯的 - 除了一些緩衝區溢出,我不明白他們是什麼意思。

我可以假設OOMPH啓動和GWT編譯的性能是相關的,所以我使用編譯時間作爲各種更改之間的基準。
我已經激活並停用了BIOS中的超線程和turbo-boost,但是再次看到沒有區別。超線程似乎使一切都變得更慢,我可以假設16個內核的上下文切換懲罰比8個內核更高。渦輪增壓似乎沒有做任何事情,我可以認爲它只適用於Win7下,我沒有成功地激活驅動程序。它應該將核心從2.5Ghz提升到2.8Ghz。
取消激活NTFS驅動器上的索引和時間戳,將性能設置從前臺更改爲後臺,並使用另一個Eclipse實例 - 無需更改。
對於編譯,我試過指定不同數量的工人,更大的內存和一些其他選項。兩名工人之上的所有東西都會增加編譯時間
較舊的惠普機器(XW6600)似乎編譯速度更快,可能是因爲2.8GHz時鐘,但其主機模式似乎啓動較慢。
如何提高GWT託管模式/編譯時間?

綜上所述,內存的使用是在約2.6GB,頁面文件的用法是零,硬盤沒有信令多活動,CPU活動< 10%(在約50-70%的單核),但仍然在計算機在編譯或啓動OOMPH GWT的過程中似乎沒有任何作用。
好吧,現在我已經試過了解我在互聯網上發現的一切,還有什麼可以嘗試的嗎?切換到64位的Win7會有多大的改進(這是明年到期的)?有沒有我可以調整的硬件/軟件選項?

L.E .:還跑了RATT(來自MS的示蹤劑),看看是否有任何中斷時間過長,但一切似乎都是按順序的。防病毒沒有什麼區別。基於另一個GWT項目對我的i7手機(2630q)和i7的速度提高了大約70%,儘管它的時鐘大致相同。

+0

+ 1我對此也感興趣。根據我的觀察,它受CPU限制(即使CPU無法達到100%) - 從Core 2 Duo 2GHz到Core I3 2.6Ghz,主機模式的啓動時間幾乎減半。 (從〜60s到〜30s) –

回答

8

在大多數情況下,我遇到了編譯/託管模式刷新緩慢的原因,就是應用程序是這樣寫的。

編譯有幾件事情需要注意:

  • 不要將未使用的類和模塊在類路徑中,如果可能的,因爲GWT在預編譯階段
  • 豔記反正解析它們刪除出去GWT-RPC式爆炸,這通常是所有問題的原因
  • 與接口ContextWithLokup真的小心,總是儘量減少延伸ContextWithLookup
  • 嘗試在界面中使用的方法數看看一些其它編譯選項,如distributed compilationsoft permutations或多JVM編譯(運行編譯器系統屬性-Dgwt.jjs.permutationWorkerFactory = com.google.gwt.dev.ExternalPermutationWorkerFactory-localWorkers指定的JVM的數量)

對於託管模式:

  • 使用延遲加載它是可能的。託管模式我遇到的最大問題是,我應用程序試圖初始化太多甚至在當前屏幕上沒有使用的類,這可以大大加速託管模式啓動。同樣,諸如RPC類型爆炸之類的東西也會影響託管模式

這就是我所能建議的。像ram磁盤之類的東西可以加速像-compileReport這樣的東西,因爲它可以生成大量的文件。

+0

關於未使用的類的好消息,我忘記了這一點(並且我們已經覆蓋了預編譯器)。剛剛發現了'類型爆炸',但我們總是明確定義了可序列化的類型。我們通常只編譯一個排列,而我的抱怨是隻編譯一個(或者說預編譯階段),所以分佈式編譯沒有多大幫助。當地工人幾乎沒有區別。延遲加載儘可能地完成,但從這一點來說,它需要重新設計,因爲它從一開始就設計得非常糟糕。再次,未使用的模塊是一個非常好的提示! – brainwash