如何提高GWT的主机模式/编译时间？

Question

在工作中，我们使用的是一些非常强大的机器：HP Z600双路至强处理器@2.5GHz，8-16GB内存。不幸的是，由于公司政策不合适，我们被迫使用32位XP系统，因此我将未使用的4GB RAM制作成了PAE RAM驱动器。
现在，临时文件存储在RAM驱动器上。我还尝试将整个项目移动到RAM驱动器上，然后移到SSD上，但是托管模式启动或编译时间没有明显改善。
然后我运行了SysInternals的Process Monitor来查看是否有任何瓶颈，这些瓶颈在任务管理器/硬盘活动指示灯中不可见，但我并没有看到什么值得注意的问题 - 除了一些我不理解其含义的缓冲区溢出。

我可以假设OOMPH启动和GWT编译的性能是相互关联的，因此我使用编译时间作为各种更改之间的基准测试。
我在BIOS中激活和停用了超线程和Turbo Boost，但是仍然没有看到任何差异。超线程甚至似乎使一切变慢，我可以假设对于16个核心而言，上下文切换惩罚要比8个核心更高。Turbo Boost似乎没有起作用，我无法激活驱动程序。它应该将核心从2.5GHz提升到2.8GHz。
在NTFS驱动器上停用索引和时间戳，将性能设置从前台更改为后台并返回，使用另一个Eclipse实例 - 没有变化。
对于编译，我尝试指定不同数量的工作线程、更大的内存和一些其他选项。超过两个工作线程的所有内容都会增加编译时间。
旧的HP机器（XW6600）似乎编译速度略快，可能是因为2.8GHz时钟，但其托管模式启动速度较慢。

总之，内存使用率约为2.6GB，页面文件使用率为零，硬盘活动不多，CPU活动<10%（单个核心约为50-70%），但在编译或启动OOMPH GWT时计算机仍然似乎无所作为。
好的，既然我已经尝试了我所知道的和在互联网上找到的一切，还有其他我可以尝试的吗？转换到64位Win7系统会有很大的改善吗（这将在明年进行）？有什么硬件/软件选项可以调整？

L.E.：还运行了RATT（MS的跟踪器），以查看是否有任何中断时间过长，但是一切似乎都很正常。杀毒软件没有什么区别。将另一个GWT项目与我的i7移动版（2630q）进行基准测试，i7速度约快70％，尽管它具有相同的时钟频率。

- brainwash

---

+1 我也对此很感兴趣。从我的观察来看，它是CPU绑定的（即使它没有将CPU利用率提高到100%），从2GHz的Core 2 Duo到2.6GHz的Core I3，在托管模式下启动时间几乎缩短了一半。（从约60秒缩短至约30秒） - Ioan Agopian

Answer 1

在我遇到的大多数情况下，编译/托管模式刷新缓慢的原因是应用程序编写方式造成的。

对于编译，有几个要注意的事项：

• 不要在类路径中保留未使用的类和模块，如果可能，请将它们删除，因为 GWT 在预编译阶段仍会解析它们
• 注意 GWT-RPC 类型爆炸，这通常是所有问题的根源
• 非常小心接口 ContextWithLokup，始终尝试最小化扩展 ContextWithLookup 的接口中使用的方法数量
• 尝试检查一些其他编译选项，例如 分布式编译，软件排列 或多 JVM 编译（使用系统属性 -Dgwt.jjs.permutationWorkerFactory=com.google.gwt.dev.ExternalPermutationWorkerFactory 和 -localWorkers 来指定 JVM 数量来运行编译器）

对于托管模式：

• 尽可能使用延迟加载。我看到托管模式的最大问题是，应用程序试图初始化太多甚至在当前屏幕上都没有使用的类，这可以大大加快托管模式的启动速度。同样，像RPC类型爆炸之类的东西也会影响托管模式。

这就是我能提供的所有建议。像RAM磁盘这样的东西可以加快-compileReport之类的东西，因为它可以生成大量文件。

- jusio

---

关于未使用的类的提示很好，我忘记了这一点（而且我们已经覆盖了预编译器）。刚刚发现了“类型爆炸”，但我们总是明确定义可序列化类型。我们通常只编译一个排列，我的抱怨是只编译一个（或者更准确地说是预编译阶段），因此分布式编译帮助不大。Localworkers 几乎没有什么区别。尽可能进行惰性加载，但从这个点开始，需要重新设计，因为从一开始就设计得很糟糕。再次强调，未使用的模块是一个非常好的提示！ - brainwash