EclipseRCP:-如果视图包含巨大的选择，比如4000个对象，那么应用程序需要时间来显示上下文菜单

我们已经在EclipseRCP框架上构建了一个大型应用程序。如果选择了大量对象（例如4000或5000个对象），我们将在整个应用程序中面临这个问题。在这种情况下，以下操作需要时间，UI处于无响应状态。 1.选择并右键单击关联菜单显示 2.保留选择，更改视图并返回到早期视图。 3.保留选择，更改应用程序（如excel、word）并返回查看

我的分析表明，EclipseRCP需要时间来评估当前选定对象的菜单贡献和处理程序。我们还使用嵌套在迭代表达式中的属性测试程序，我认为这需要时间来评估。痛苦的是每次我切换视图时它都会进行评估，并且不会缓存结果

我需要你的意见： 以前有没有其他人遇到过这个问题？有什么好方法可以处理处理程序中的大量选择，菜单贡献，从而提高性能

提前谢谢。

---

~Prasad

主要的问题可能是你的属性测试仪，因为每次你的应用程序中出现视觉变化时，都会对这些测试仪进行评估：打开新的shell（如菜单、对话框、向导等），或者展开/折叠某个面板，或者切换透视图或视图/编辑器，或者切换应用程序

作为第一步，您可以尝试禁用它们（或使它们为虚拟，不做任何事情/或持续操作），以查看它是否会影响应用程序的性能。如果确实如此，那么您可能会考虑重新设计应用程序，并使用

org.eclipse.ui.AbstractSourceProvider

和

org.eclipse.ui.contexts.IContextService

的组合来替换属性测试程序

当然，我不确定您的真实用例，但这里有一些想法：

源提供程序也可以在plugin.xml中用作变量

然后，您可以注册一组上下文（当然，我不确定关于真实用例的情况，只是在这里建议），这些上下文可以在某些条件下通过编程激活：

最终IContextService contextManager=（IContextService）activeWorkbenchWindow.getService（IContextService.class）； activateContext（“您的上下文id”）

另一个步骤是注册上下文激活侦听器：

    final IContextService contextManager = (IContextService) activeWorkbenchWindow.getService(IContextService.class);
    contextManager.addContextManagerListener(new IContextManagerListener() {

            @Override
            public void contextManagerChanged(ContextManagerEvent contextManagerEvent) {
                if (!contextManagerEvent.isActiveContextsChanged()) {
                    return;
                }
               [process context changes: possibly notify source providers about context changes]
            }
     });

使您的SourceProvider在实际更改某些内容时侦听上下文更改并刷新状态：

@Override
public void contextActivated() {
    fireSourceChanged(getSourcePriority(), refreshState());
}

如果在您的应用程序中不是这样或不可能，那么，其他一些解决方法可能是在源提供程序中引入缓存或提高算法性能，例如，通过与多线程并行执行一些长时间运行的操作。如果您使用的是Java8，这应该相当容易

当然，总有这样一种情况，SWT自身重新绘制所有小部件的速度很慢——在这种情况下，您可能需要考虑使用性能更好的标准SWT小部件的替代品。例如，使用Nattable而不是默认的SWT/JFace查看器

---

我希望这能给你一些想法。

你可以尝试从eclipse Api将它们加载到另一个线程中，比如Job和UIJob。这个评估是从eclipse框架代码中进行的，我们如何将其包装到UIJob中？哦，别担心，我误解了你的问题！对不起，亚历克斯，谢谢你的帮助。我们还同时致力于修复性能测试仪。但我注意到的是，对于每个选择，Eclipse框架会对选择进行3次评估，即每个属性测试人员都会被评估3次，这看起来是不必要的。正如我已经提到的：在Eclipse RCP:）中，属性测试人员会在“每个喷嚏”上重新评估，所以如果您进行调试，您可能会注意到，这种重新评估的主要事件在某个地方，SWT在那里处理它的事件，并且很可能得到某种UI重画事件。