使用DOM元素的GWT操作的性能价格是否真的很高?

时间:2013-02-14 11:46:26

标签: javascript performance gwt dom

我想要的是了解我为GWT所做的DOM操作支付的性能价格。我想知道哪些操作“昂贵”而哪些操作不是,以及如何测量它。我想知道如何描述这些操作,或者根本不值得关注这些问题。

更确切地说,这是我遇到的用例列表。

1)用例#1:如果某个事件发生,你有一个小部件可以改变它的外观。如果我要移除旧窗口小部件并创建新窗口小部件,或者更好地更改现有窗口小部件的样式,是否有任何区别?换句话说,在GWT应用程序中创建和插入新小部件的价格有多大?是否有任何类型的垃圾收集器用于删除DOM元素?

2)用例#2:您需要从服务器端获取或保存一些数据。数据可能非常大。有没有意义创建一个特殊的Servlet,它将以非常简单的方式进行此操作:只接受或打印一些String而不是对标准GWT servlet进行RPC调用?这是提高绩效的好方法吗?您自编的Servlet非常简单。

3)用例#3:你有一个小部件是一个很长的其他小部件列表。如何估计哪些小部件可以安全地显示客户端性能?我的意思是,如果过去5年我们会显示500万条聊天消息,可能客户端会变慢,即使我们会逐个加载项目,从而限制了服务器端的压力。

4)用例#4:dom操作的性能价格如何找出某个容器内部的元素数量,或者找出元素的样式?例如,您需要计算聊天中的消息数。这个计算聊天容器的DOM子项的操作是否昂贵以至于更好地实现单独的计数器并在新消息到达时增加它(就像Java Collections一样)?

1 个答案:

答案 0 :(得分:5)

Use case #1: Updating style is always recommended rather than remove/add widget。更新样式意味着CSS解析/重新计算/绘制。删除/添加小部件将导致DOM& CSS解析/重新计算/绘画。

Use Case #2:这取决于你的操作。 GWT带有三种服务器端通信。它们中的每一个都适用于不同的用例 - 阅读here

a) RPC - Remote Procedure calls
b) RF - Request Factory & Entities
c) Request Builder with self-written Servlet serving up Strings,JSON or Autobean.

Use Case #3:您有GWT Cell Widgets以最少的DOM操作显示大数据。如果显示聊天消息,则需要在滚动时尝试使用AutoPager进行CellList,并且可能会抛出异步数据提供者。

Use case #4:您应该使用Java Pojo支持的Cell Widgets。每个聊天消息都是Java Pojo“ChatMessage”的实例,并根据您的RPC调用获取List并将其提供给CellList / CellTable。当你可以通过List上的sizeOf操作来计算“数据”时,为什么你会计算dom。

你正在以错误的方向思考你的项目。如果编程方法错误,DOM操作是一个问题。通过下载GWT Files来浏览GWT样本并通过导入到eclipse来执行它们。

性能调优是GWT最强大的功能。有了足够的经验,您可以使用SpeedTracer, Logging, Chrome Dev tools Profiling, GWT Light Weight Metrics, Code Splitting, GWT Compiler Metrics, GWT Closure Compiler, Resource Bundling and the list goes on....

来消除GWT中的任何性能问题