错误的GWT请求对象列表的工厂性能

Question

我正在通过GWT Request Factory将对象列表传输到客户端。对象只包含几个字符串，列表只包含20个对象。要传输这个小数据列表，需要一秒钟。首先，我认为需要优化查询。但测量显示：

从数据库中检索对象只需

300ms

转移到客户端的时间总计超过一秒

1136ms

所以这似乎是请求工厂开销。我已经使用了自己的ServiceLayerDecorator并覆盖了isLive()函数，因此它始终返回true。我可以采取任何其他措施加快速度并将性能提升到可接受的范围吗？

更新

我创建了将我的实体对象数据复制到DTO并使用RPC传输它们以比较RPC和Request工厂性能的逻辑。如您所见，RPC逻辑要快得多。现在我想知道这是设计还是我的申请中存在缺陷。

20个转移的对象：

Request factory: 1252 ms

RPC: 420 ms

28个转移的对象：

Request factory: 1654 ms

RPC: 460 ms

78个转移的对象：

Request factory: 3963 ms

RPC: 769 ms

=============================================== =============

UPDATE2

所以我编写了一个非常简单的示例应用程序，以确保我的应用程序没有任何过滤器或其他干扰组件。应用程序从服务器加载10个带有4个String字段的对象。我使用Request工厂和RPC完成了它并停止了时间。

代码可以在这里找到： https://github.com/jan10101/requstFactoryVSRPC

这里的生活演示： http://requestfactorytest.appspot.com/

测试应用程序证实了我的观察结果：与RPC性能相比，请求工厂性能非常糟糕。在开发模式下，RPC的性能大约高出40倍，在生产模式下仍然是4倍。我是第一个注意到性能问题的人吗？

以下屏幕截图显示了测试结果，如果您不想自己尝试。

开发模式的结果：

生产代码的结果（在应用引擎上）：

Answer 1

我不确定这与您的具体情况有多相关，但问题可能是AutoBeans。 RequestFactory广泛使用AutoBeans。

我最近能够通过减少AutoBeans的使用来解决GWT应用程序中的性能问题，这似乎非常慢。使用层次性性能分析器（例如IE的F12工具中的那个）将Autobean代码识别为问题的根源，因此性能问题是客户端问题。 IIRC的解决方案是在完成调用后将AutoBeans复制到“真正的”Java对象。