Uh oh!
There was an error while loading. Please reload this page.
[performance] Import the large project - #17
Conversation
e42b1ae to
9ae8b3dCompare6d3a529 to
87cc953Compare1c87a87 to
f4f63c7Comparesnjeza
commented
Dec 3, 2025
The PR includes the folowing changes:
cc @guw |
guw
left a comment
There was a problem hiding this comment.
This PR mixes programming changes with performance fixes. It needs to be separated. So the performance improvements can be inspected separate from job/thread/scheduling changes.
The use of jobs framework is preferred. Thus, any removal of this needs really good data on why this is needed.
| } finally { | ||
| try { | ||
| refreshResources(resourcesToRefresh, monitor); | ||
| //refreshResources(resourcesToRefresh, monitor); |
| // loads can be potentially expensive; we synchronize on the location | ||
| var location = getLocation(); | ||
| var openJob = new BazelElementOpenJob<>(location != null ? location : IPath.ROOT, this, infoCache); |
There was a problem hiding this comment.
Eliminating the job removes transparency and visibility into the package. The job framework provides valuable insights in the Eclipse UI. I would rather like to see JDTLS improve here.
The second important thing provided by jobs framework is synchronization using ISchedulingRule. It is important that at most ONE Bazel command is executed per workspace in general. The Bazel client prevents concurrent executions usually, which can lead to unexpected pauses/waits when multiple Bazel commands are executed by different threads. The job framework (again) helps visualizing this in the UI.
| * @return | ||
| */ | ||
| public abstract <I extends BazelElementInfo> I putOrGetCached(BazelElement<I, ?> bazelElement, | ||
| Supplier<I> supplier); |
There was a problem hiding this comment.
The use of supplier adds unwanted complexity. I experimented with suppliers here in the past. However, it was discarded because we do not want to allow computation by direction. We rather like to be in control of when Bazel commands are executed and how.
| private volatile Map<String, BazelRuleAttributes> externalRepositoryRuleByName; | ||
| private volatile Map<BazelLabel, IProject> projectByLabel = new HashMap<>(); |
There was a problem hiding this comment.
If we start caching these here we need some logic in the manager to invalidate when users open/close projects.
| .collect(toMap(BazelRuleAttributes::getName, Function.identity())); // index by the "name" attribute | ||
| } | ||
| public void put(BazelLabel label, IProject project) { |
There was a problem hiding this comment.
A public put is problematic. What is the reason for this?
| // during synchronization resource changes may occur; however, they are triggered by the synchronization activities | ||
| // therefore we suspend cache invalidation of the model due to resource changes | ||
| workspace.getModelManager().getResourceChangeProcessor().suspendInvalidationFor(workspace); | ||
| workspace.getModelManager().getResourceChangeProcessor().suspendInvalidationFor(workspace.getModel()); |
| public Map<BazelPackage, Map<String, Target>> queryForTargetsWithDependencies(BazelWorkspace bazelWorkspace, | ||
| Collection<BazelPackage> bazelPackages, BazelElementCommandExecutor bazelElementCommandExecutor) | ||
| throws CoreException { | ||
| // bazel query 'kind(rule, deps(//foo:all + //bar:all))"' |
There was a problem hiding this comment.
This looks like an interesting optimization for removing bazel query calls. Please submit as separate PR/commit
snjeza
commented
Dec 9, 2025
@guw I have created separate PRs: |
Fixes#16
Steps to test:
to .eclipse/.bazelproject
-Xmx10G -Xms4g -Declipse.bazel.model.cache.expireAfterAccessSeconds=86400 -Djdk.xml.elementAttributeLimit=0to Eclipse