Closed jfehrle closed 1 year ago
thank for the report, a file in particular ?
Try opening tactics.ml
and stm.ml
from https://github.com/coq/coq at the same time. Maybe also open tabs for tactics.mli
and stm.mli
. (I synced a couple weeks ago to ae832eb05c17539448cd63f99a9bbe062126c785, but I likely master
would give the same behavior.)
However, I'm not seeing quite the same level of CPU use this morning--I've not done any real work in IJ yet today after hibernating overnight. 30-50 percent at times. Clicking in the panels seems to push up the level.
I would guess the plugin code is run too often and (obviously) in multiple threads.
Hope you're able to see the problem.
I've also gotten 9 exceptions that appear to be similar to this one:
com.intellij.psi.stubs.UpToDateStubIndexMismatch: PSI and index do not match.
Please report the problem to JetBrains with the files attached
INDEXED VERSION IS THE CURRENT ONE file=orderedType.ml, file.class=class com.reason.ide.files.OclFile, file.lang=Language: OCaml, modStamp=0
tree consistent
stub debugInfo=created in getStubTree(), with AST = false; with backReference
viewProvider=com.intellij.psi.SingleRootFileViewProvider{vFile=file:////wsl$/Ubuntu/home/proj/coq2/clib/orderedType.ml, vFileId=50536, content=VirtualFileContent{size=1160}, eventSystemEnabled=true}
viewProvider stamp: 0; file stamp: 0; file modCount: 1655221498412; file length: 1160
doc saved: true; doc stamp: 0; doc size: 1160; committed: true
indexing info: indexing timestamp = 1655221498412, binary = false, byte size = 1160, char size = 1160
latestIndexedStub=StubTree{myDebugInfo='created from index; with backReference', myRoot=OclFileStub}2025530813
same size=true
debugInfo=created from index; with backReference
at com.intellij.psi.stubs.StubTreeLoader.handleUpToDateMismatch(StubTreeLoader.java:218)
at com.intellij.psi.stubs.StubTreeLoader.access$100(StubTreeLoader.java:28)
at com.intellij.psi.stubs.StubTreeLoader$StubTreeAndIndexUnmatchCoarseException.doCreateCompleteException(StubTreeLoader.java:210)
at com.intellij.psi.stubs.StubTreeLoader$StubTreeAndIndexUnmatchCoarseException.access$300(StubTreeLoader.java:151)
at com.intellij.psi.stubs.StubTreeLoader.lambda$stubTreeAndIndexDoNotMatch$0(StubTreeLoader.java:73)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:679)
at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:635)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$computeInNonCancelableSection$4(CoreProgressManager.java:230)
at com.intellij.openapi.progress.Cancellation.computeInNonCancelableSection(Cancellation.java:99)
at com.intellij.openapi.progress.impl.CoreProgressManager.computeInNonCancelableSection(CoreProgressManager.java:230)
at com.intellij.psi.stubs.StubTreeLoader.stubTreeAndIndexDoNotMatch(StubTreeLoader.java:72)
at com.intellij.psi.stubs.StubProcessingHelperBase.inconsistencyDetected(StubProcessingHelperBase.java:151)
at com.intellij.psi.stubs.StubProcessingHelperBase.checkType(StubProcessingHelperBase.java:93)
at com.intellij.psi.stubs.StubProcessingHelperBase.processStubsInFile(StubProcessingHelperBase.java:72)
at com.intellij.psi.stubs.StubIndexEx.lambda$processElements$4(StubIndexEx.java:146)
at com.intellij.psi.stubs.StubIndexEx.processElements(StubIndexEx.java:210)
at com.intellij.psi.stubs.StubIndex.getElements(StubIndex.java:102)
at com.intellij.psi.stubs.StubIndex.getElements(StubIndex.java:90)
at com.reason.ide.search.index.ModuleIndex.getElements(ModuleIndex.java:24)
at com.reason.ide.go.ORModuleContributor.processElementsWithName(ORModuleContributor.java:52)
at com.intellij.ide.util.gotoByName.ContributorsBasedGotoByModel.processContributorForName(ContributorsBasedGotoByModel.java:207)
at com.intellij.ide.util.gotoByName.ContributorsBasedGotoByModel.lambda$getElementsByName$3(ContributorsBasedGotoByModel.java:182)
at com.intellij.concurrency.JobLauncherImpl.lambda$processImmediatelyIfTooFew$2(JobLauncherImpl.java:137)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$13(CoreProgressManager.java:604)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:679)
at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:635)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:603)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60)
at com.intellij.concurrency.JobLauncherImpl.lambda$processImmediatelyIfTooFew$3(JobLauncherImpl.java:133)
at com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(ApplicationImpl.java:865)
at com.intellij.concurrency.JobLauncherImpl.processImmediatelyIfTooFew(JobLauncherImpl.java:144)
at com.intellij.concurrency.JobLauncherImpl.invokeConcurrentlyUnderProgress(JobLauncherImpl.java:44)
at com.intellij.concurrency.JobLauncher.invokeConcurrentlyUnderProgress(JobLauncher.java:51)
at com.intellij.ide.util.gotoByName.ContributorsBasedGotoByModel.getElementsByName(ContributorsBasedGotoByModel.java:183)
at com.intellij.ide.util.gotoByName.DefaultChooseByNameItemProvider.processByNames(DefaultChooseByNameItemProvider.java:255)
at com.intellij.ide.util.gotoByName.DefaultChooseByNameItemProvider.filterElements(DefaultChooseByNameItemProvider.java:117)
at com.intellij.ide.util.gotoByName.DefaultChooseByNameItemProvider.lambda$filterElementsWithWeights$3(DefaultChooseByNameItemProvider.java:75)
at com.intellij.openapi.progress.impl.CoreProgressManager.computePrioritized(CoreProgressManager.java:787)
at com.intellij.ide.util.gotoByName.DefaultChooseByNameItemProvider.filterElementsWithWeights(DefaultChooseByNameItemProvider.java:74)
at com.intellij.ide.actions.searcheverywhere.AbstractGotoSEContributor.lambda$fetchWeightedElements$4(AbstractGotoSEContributor.java:239)
at com.intellij.openapi.application.impl.ApplicationImpl.tryRunReadAction(ApplicationImpl.java:1102)
at com.intellij.openapi.progress.util.ProgressIndicatorUtils.lambda$runInReadActionWithWriteActionPriority$0(ProgressIndicatorUtils.java:72)
at com.intellij.openapi.progress.util.ProgressIndicatorUtilService.runActionAndCancelBeforeWrite(ProgressIndicatorUtilService.java:63)
at com.intellij.openapi.progress.util.ProgressIndicatorUtils.runActionAndCancelBeforeWrite(ProgressIndicatorUtils.java:129)
at com.intellij.openapi.progress.util.ProgressIndicatorUtils.lambda$runWithWriteActionPriority$1(ProgressIndicatorUtils.java:110)
at com.intellij.openapi.progress.ProgressManager.lambda$runProcess$1(ProgressManager.java:70)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:186)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$13(CoreProgressManager.java:604)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:679)
at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:635)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:603)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:173)
at com.intellij.openapi.progress.ProgressManager.runProcess(ProgressManager.java:70)
at com.intellij.openapi.progress.util.ProgressIndicatorUtils.runWithWriteActionPriority(ProgressIndicatorUtils.java:107)
at com.intellij.openapi.progress.util.ProgressIndicatorUtils.runInReadActionWithWriteActionPriority(ProgressIndicatorUtils.java:72)
at com.intellij.ide.actions.searcheverywhere.AbstractGotoSEContributor.fetchWeightedElements(AbstractGotoSEContributor.java:265)
at com.intellij.ide.actions.searcheverywhere.PSIPresentationBgRendererWrapper.fetchWeightedElements(PSIPresentationBgRendererWrapper.java:67)
at com.intellij.ide.actions.searcheverywhere.MixedResultsSearcher$ContributorSearchTask.run(MixedResultsSearcher.java:183)
at com.intellij.util.ConcurrencyUtil.runUnderThreadName(ConcurrencyUtil.java:227)
at com.intellij.util.ConcurrencyUtil.lambda$underThreadNameRunnable$3(ConcurrencyUtil.java:215)
at com.intellij.openapi.application.impl.ApplicationImpl$1.run(ApplicationImpl.java:252)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:702)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:699)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:699)
at java.base/java.lang.Thread.run(Thread.java:833)
Ah, if I now open an editor for orderedType.ml
(the file mentioned on the 6th line of the exception above ("viewProvider= ...."), IJ jumps to 88 % CPU use and my computer is pinned at 100% as long as that editor panel is visible in IJ (even while I minimize the IJ window and switch to a browser window).
It may be that there are two performance issues: the 100% case and the 30-50% case.
can it be a wsl problem ? I have spikes when opening the files, but they don’t last long. what if you open these files from a pure windows env (local file system) ?
Hmm, I didn't see the problem in a quick experiment with the same file. Perhaps it will go away when I upgrade to Windows 11--I've been putting that off.
I found that I am doing unneeded operations. I have a simpler implementation.
However, in my env, opening heap.ml
generates a lot of CPU usage.
The problem come from module type S =sig
, if I rename it to Sxxx
CPU drops. So it might be a problem with resolution of the result type, maybe in functors
I may have identified a potential problematic code in the gutter navigation
@jfehrle Hi, can you please test this version of plugin and tell me if you still have CPU usage problems ? https://plugins.jetbrains.com/plugin/9440-reasonml/versions/beta/361658
Based on a few minutes experimentation, that seems to fix the problem. When I open the files mentioned above (e.g. stm.ml, tactics.ml, heap.ml) I see a brief jump in CPU use, which then drops to low levels.
Thanks for the fix!
Cool.
It's not a fix yet because there might be some regression with gutter navigation.
Fixed in 0.115
plugin version: 0.113-2023.1
Description
I'm seeing excessive CPU when I have large(?) .ml or .mli files visible (i.e. showing the full edit panel, not just having a tab open). I have a 6 core, 12 thread system. If I have 2 files visible (using split screen), I can easily see 50% CPU utilization by IntelliJ and sometimes 90+%. If I switch to edit panels that don't have those suffixes, CPU use drops quickly and stays low.
Having at least one of the files large (> 5000 lines) seems to make it more likely that I see the problem, but I can also see it when both files are only a couple hundred lines.
I could try further experiments if you like.
I first noticed this behavior maybe a month ago, perhaps when I updated IJ and the plugin.