我有一个eclipse插件，其中存在一些性能问题。从进度视图来看，有时会有多个作业在等待，并且从代码的角度来看，大多数架构都基于扩展了j和devtools::install_github("ben519/mltools")
require(mltools)
dt <- data.table(
intCol=c(1L, NA_integer_, 3L, 0L),
realCol=c(NA, 2, NA, NA),
logCol=c(TRUE, FALSE, TRUE, FALSE),
ofCol=factor(c("a", "b", NA, "b"), levels=c("a", "b", "c"), ordered=TRUE),
ufCol=factor(c("a", NA, "c", "b"), ordered=FALSE)
)
sparsify(dt)
sparsify(dt, sparsifyNAs=TRUE)
sparsify(dt[, list(realCol)], naCols="identify")
sparsify(dt[, list(realCol)], naCols="efficient")
事件的类。当前的解决方案还涉及嵌套作业...
我阅读了文档，理解了它们的用途，但我不明白为什么我可以使用在总线上发送事件时触发的方法运行WorkspaceJobs时使用工作区作业的原因？
例如，我可以创建一个事件来触发将执行Guava EventBus的事件，而不是创建三个彼此等待的作业，然后在该方法完成后，它将发送不同的事件类型，该事件类型将触发执行syncexec/asyncexec将要执行的操作的方法，依此类推...
所以代替：
Job 1我可以使用：
Job 2我还没有尝试过，因为我尽了最大努力简化了构想，并且问题比这更复杂，但是我认为WorkspaceJob Job1 = new WorkspaceJob("Job1");
Job1.schedule();
WorkspaceJob Job2 = new WorkspaceJob("Job2");
Job2.schedule();
WorkspaceJob Job1 = new WorkspaceJob("Job3");
Job3.schedule();
在性能上胜过{{1 }}。
任何人都可以确认我的想法或告诉我为什么我不应该尝试此操作（除了我必须对自己的事件有很好的了解之外）？
答案 0 :(得分：2)
WorkspaceJob延迟资源更改事件，直到作业完成。这样可以防止侦听资源更改的组件收到一半完成的更改。这可能对您的应用程序很重要，也可能不重要。
我无法对Guava代码发表评论，因为我对此一无所知-但请注意，如果您的代码运行时间长，则必须确保其在后台线程中运行（WorkbenchJob会这样做）。