我应该如何使用 MVC 来加速缓慢的 GWT 应用程序
我已将我的应用程序更改为使用 MVC，但它变得非常慢。
描述：
- 该应用程序有 5 个组合，每个组合代表不同的数据，并且并不总是显示
- 该应用程序正在使用 MVC，并且在发生更新时我将模型传递给每个组合。
- 每次收到通知时，我都会重建一棵树（以及所有树项目），但是，只有一个树项目会发生变化，因此这可能是一种浪费。
- 由于应用程序的风格，我什至必须通知（）一些无关紧要的事情，例如更改文本框中的文本或选择菜单，因为我有一个已保存的图标，每当树项中的某些内容发生更改时，该图标就会变为未保存。
- 所有组合都实现相同的观察者接口，因此所有组合都会在每个notify() 上得到更新。
有人可以给我一些关于我应该做什么来加速这个应用程序的提示吗？上面哪一个可能比其他的更需要 CPU，即用 << 重建一棵树。每个notify() 上有20 个项目将使用那么多CPU 时间，我需要重新设计吗？我是否应该创建一个单独的接口，例如 SaveStateChanged ，它只会通知树，或者这只是浪费时间。
I have changed my app to use MVC and it has gotten pretty slow.
Description:
- The application has a number of 5 composites, each composite represents different data and is not always showing
- The app is using MVC and I am passing the model to each composite when an update occurs.
- I am rebuilding a Tree (and all tree items) every time a notify is recieved, however, only one of the tree items would have changed, so this is possibly a waste.
- Due to the style of the app I have to even notify() for insignificant things like changing the text in a text box or selecting a menu because I have a saved icon that turn to unsaved whenever something is changed in the tree Item.
- All the composites are implementing the same Observer Interface, so all are getting updated on every notify().
Can someone give me some tips on what I should do to speed this app up. Which of the above might be more CPU hungry than others, ie, is rebuilding a Tree with < 20 items on every notify() going to use that much CPU time, do I need to re-design this? Should I create a seperate interface such as SaveStateChanged that will only notify the tree, or is this just a waste of time.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当应用程序变得缓慢时，大多数时间通常不会花在执行 JavaScript 计算本身上（例如，我不相信，仅仅调用很多观察者就是一个问题 - 这取决于他们做什么做！）。很多时候，缓慢是由诸如冗余布局之类的事情引起的（例如，当每个观察者引起布局调用时）。有时，大量 DOM 操作也可能是一个问题（主要是使用 Internet Explorer）。
我建议尝试一下 Speed Tracer，尤其是 冗余布局示例。如果这不是您的应用程序中的特定问题，您应该能够采用示例中所示的类似方法来跟踪它。使用
markTimeline("String")来使代码的特殊部分清楚地显示在 Speed Tracer 的图表中。When an application is getting slow, then most time is often not spent performing the JavaScript calculations themselves (e. g. I don't believe, that just calling a lot of observers is a problem - it depends on what they do!). Very often, slowness is caused by things like redundant layout (e. g. when each of the observers causes a layout call). Sometimes, lots of DOM manipulations can also be a problem (mainly with Internet Explorer).
I would suggest to play a little bit with Speed Tracer, especially the redundant layout example. If that's not the specific problem in your application, you should be able to take a similar approach as shown in the example to track it down. Use
markTimeline("String")to make special parts of your code show up clearly in Speed Tracer's graphs.您需要采取的第一步是准确隔离出现性能问题的位置。您已经确定了一些可能的良好候选人，但您需要用冷酷的统计数据来支持这一点。
您可能会发现您只需要解决上述几点之一，或者可能完全存在另一个症结点
The first step you need to take is to isolate exactly where the performance problem is occurring. You've identified some good possible candidates, but you'll want to back that up with cold hard stats.
You may find you only need to address one of the above points, or that there might be another sticking point entirely
我建议您放弃观察者界面，转而采用更细粒度的界面。查看 Swing 中的 MVC 体系结构，其中 JTree 与 TreeModel 关联，并实现 TreeModelListener 接口以听取模型的更改。 TreeModelListener 接口具有由模型调用的特定方法来指示节点更改、添加或从树中删除。此外，它还有一个 TreeModelEvent，它提供了有关哪些节点受影响的更多数据。如果模型准确地告诉您发生了什么变化，您将有更大的范围从侦听器实现中做出智能反应。
I suggest you get rid of the Observer interface in favour of something more finegrained. Look at the MVC architecture in Swing where a JTree is associated with a TreeModel and implements TreeModelListener interface to hear of changes to the model. The TreeModelListener interface has specific methods called by the model to indicate nodes changing, being added or removed from the tree. In addition it has a TreeModelEvent which provides even more data about which nodes are affected. If the model tells you precisely what has changed you will have a lot more scope for reacting intelligently from your listener implementations.