Opening a file takes 4 seconds

Hi,

In IntelliJ 10.5.2 on Linux, if I open a file, IntelliJ hangs 4 seconds, then shows the file. If I close the tab, then open it again, IntelliJ again takes 4 seconds.

When searching through all files for text, IntelliJ can immediately show the search results and their contents. But as soon as you open it as a file to edit, it again needs its 4 seconds. It already knows the contents of the file immediately, but somehow when you want to edit the file it decides that it should take 4 seconds.

It doesn't depend on the programming language, it's with any file, even plain text files.

Whatever IntelliJ is doing during opening a file: Can I somehow make it stop? I don't care if IntelliJ "needs" to do this 4-second thing to update its "list of watched files" or whatever, its file watching isn't actually working anyway.

Is there any setting for this? I didn't find any. Are there any other ways to change settings in IntelliJ outside of its "Settings" UI? Is there any other way for me to tell IntelliJ to not do certain things that are annoying and slow?

I really can't stand this 4 second thing anymore. Browsing through classes and their implementations is very slow and annoying this way. You may think 4 seconds for every single file isn't much, but just try to navigate through huge OO structures this way to find the implementation you want.

This happened to me both in IntelliJ 10.5.2, and a version before this. But in 9 it didn't.

Any ideas on how to get rid of this very annoying, painful, wait?

Thanks!

3 comments

/removed detailed info/

Message was edited by: Aardwolf

0

It seems the problem is already solved:
http://youtrack.jetbrains.net/issue/IDEA-73534.

"Aardwolf" <no_reply@jetbrains.com> сообщил(а) в новостях
следующее:30743132.1001321977091500.JavaMail.devnet@confluence.jetbrains.net...

Hello,

>

Is it ok if, instead of providing full thread dumps, I just post the
following about the thread dumps? I did a diff between a jstack threaddump
while IntelliJ is doing nothing, and, during the 4 seconds it opens a file
(a well timed hitting of "enter" in the terminal
).
There weren't a lot of large differences between the two thread dumps,
except for this:

>

In the thread dump where it's doing the 4-second thing, the thread called
AWT-EventQueue-1 is RUNNABLE, and it's busy here:

>

    at java.lang.String.regionMatches(String.java:1388)
    at com.intellij.openapi.util.io.FileUtil.startsWith(FileUtil.java:767)
    at com.intellij.openapi.util.io.FileUtil.startsWith(FileUtil.java:759)
    at
com.intellij.openapi.vfs.impl.local.LocalFileSystemImpl.a(LocalFileSystemImpl.java:176)
    at
com.intellij.openapi.vfs.impl.local.LocalFileSystemImpl.access$000(LocalFileSystemImpl.java:45)
    at
com.intellij.openapi.vfs.impl.local.LocalFileSystemImpl$2.run(LocalFileSystemImpl.java:268)
    at
com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(ApplicationImpl.java:777)
    at
com.intellij.openapi.vfs.impl.local.LocalFileSystemImpl.c(LocalFileSystemImpl.java:264)
    at
com.intellij.openapi.vfs.impl.local.LocalFileSystemImpl.addRootToWatch(LocalFileSystemImpl.java:342)
    at
com.intellij.openapi.fileEditor.impl.FileEditorManagerImpl.openFileImpl3(FileEditorManagerImpl.java:776)
    at
com.intellij.openapi.fileEditor.impl.FileEditorManagerImpl$7.run(FileEditorManagerImpl.java:624)
    at
com.intellij.openapi.command.impl.CommandProcessorImpl.executeCommand(CommandProcessorImpl.java:108)
    at
com.intellij.openapi.command.impl.CommandProcessorImpl.executeCommand(CommandProcessorImpl.java:91)
    at
com.intellij.openapi.command.impl.CommandProcessorImpl.executeCommand(CommandProcessorImpl.java:79)
    at
com.intellij.openapi.fileEditor.impl.FileEditorManagerImpl.openFileImpl2(FileEditorManagerImpl.java:622)
    at
com.intellij.openapi.fileEditor.impl.FileEditorManagerImpl.openFileWithProviders(FileEditorManagerImpl.java:601)
    at
com.intellij.openapi.fileEditor.ex.FileEditorManagerEx.openFile(FileEditorManagerEx.java:132)
    at
com.intellij.openapi.fileEditor.impl.FileEditorManagerImpl$10.run(FileEditorManagerImpl.java:879)
    at
com.intellij.openapi.command.impl.CommandProcessorImpl.executeCommand(CommandProcessorImpl.java:115)
    at
com.intellij.openapi.command.impl.CommandProcessorImpl.executeCommand(CommandProcessorImpl.java:91)
    at
com.intellij.openapi.command.impl.CommandProcessorImpl.executeCommand(CommandProcessorImpl.java:79)
    at
com.intellij.openapi.fileEditor.impl.FileEditorManagerImpl.openEditor(FileEditorManagerImpl.java:876)
    at
com.intellij.openapi.fileEditor.OpenFileDescriptor.navigateInAnyFileEditor(OpenFileDescriptor.java:144)
    at
com.intellij.openapi.fileEditor.OpenFileDescriptor.navigateInEditor(OpenFileDescriptor.java:129)
    at
com.intellij.openapi.fileEditor.OpenFileDescriptor.navigate(OpenFileDescriptor.java:116)
    at
com.intellij.psi.impl.source.JavaStubPsiElement.navigate(JavaStubPsiElement.java:146)
    at
com.intellij.codeInsight.navigation.NavigationUtil.activateFileWithPsiElement(NavigationUtil.java:112)
    at
com.intellij.ide.projectView.impl.nodes.AbstractPsiBasedNode.navigate(AbstractPsiBasedNode.java:194)
    at com.intellij.util.OpenSourceUtil.navigate(OpenSourceUtil.java:51)
    at
com.intellij.util.OpenSourceUtil.openSourcesFrom(OpenSourceUtil.java:29)
    at
com.intellij.util.EditSourceOnDoubleClickHandler$TreeMouseListener.processDoubleClick(EditSourceOnDoubleClickHandler.java:128)
    at
com.intellij.util.EditSourceOnDoubleClickHandler$TreeMouseListener.mouseClicked(EditSourceOnDoubleClickHandler.java:123)

>
>

While in the thread dump with the non-busy IntelliJ, that thread is
instead in state WAITING with nothing interesting in its call stack.

>

It being busy with "startsWith" and "regionMatches" is consistent if I
retry multiple times. So it looks like double clicking to open a file,
causes it to parse huge amounts of things for "startsWith" with a
FileUtil. Why?!

>

Thanks!

>

---
Original message URL: http://devnet.jetbrains.net/message/5442998#5442998


0

Please sign in to leave a comment.