Slow editor response

[abhimodak]

Quite often the Visual Studio editor response slows down due to Fortran Integration --- Compile 19.0 update 5 (package 281) with VS2019. Eventually (sometimes) there is a pop-up (from the VS), indicating one of the extensions (Fortran IDE) is slowing things down.

There have been posts earlier indicating turning off intellisense and other options.

These options/tools are very useful; hence, what are the latest recommendations for usage of editor extensions? It does get excruciatingly slow; to the point that one is forced to close VS instance and open again. There appears some delta-time after which whatever is running in background/listening to the edits 'get tired'.... and the editor becomes useless.

Abhi

[andrew_4619]

Yup, the problem has been around for years. I never found any workaround, I got to live with closing and opening again at the first sign of the issue. I am not seeing this problem with VS2022 but that has other problems that are maybe worse for me (debugging watching). I am hoping the VS integration issues on VS2022 get fixed soon.

[Devorah_H_Intel]

@abhimodak  @andrew_4619 
Do you still experience slowness issue with VS2022? If yes, what version of VS2022 and could you provide a VS solution for us to reproduce and investigate the cause. 

[JohnNichols]

With the latest VS 2022 Preview, those old issues seem to have gone, they come back if I make a mistake and use an older VS.  I keep the older ones for other mistakes and Fortran is fast. 

[JohnNichols]

But if you go that route, do not add any Windows SDK beyond those that come with an original install, otherwise you will spend a few hours fixing the issue with IFX. 

[andrew_4619]

I am using Microsoft Visual Studio Community 2022 (64-bit) Version 17.0.5 and latest OneAPI. The problem has not gone away and was the same in VS2019 and VS2017 previously.  I will try to make a reproducer that doesn't involve my actual code. The main issue for me is submodule interface  files where we have a lot of interfere module subroutine end module subroutine end interface blocks. After a short while these become impossible to edit as every keystroke involves a long wait whilst  it rescans the document(s) or whatever it does. The answer is to close VS and reopen and then it will be OK for a short time. Editing other files isn't an issue.

[JohnNichols]

Microsoft Visual Studio Community 2022 (64-bit) - Preview
Version 17.8.0 Preview 6.0

I use this all day every day and have no editor problems.  It will coexist with all the others and is a simple load.

But an example we can test is a lot better than anything.  

[andrew_4619]

@Devorah_H_Intel  I created a solution and project attached as a zip slow-ves-edit.f90 is included but not called is is just a generator for the other three source files which consist of a module with 500 interfaces and a submodule with 500 very boring subroutine named rr1 through to rr500. Anyway open the project and have a play and within a vary short period the _if.f90 becomes very slow. Hit enter for a new line and wait a few seconds before you can do the next thing. The more you edit the longer the wait gets. Enjoy.

module slow
implicit none(type, external)
interface ! RR1
    module subroutine RR1(A, B )
        real :: A, B
    end subroutine RR1
end interface
interface ! RR2
    module subroutine RR2(A, B )
        real :: A, B
    end subroutine RR2
end interface
interface ! RR3
    module subroutine RR3(A, B )
        real :: A, B
    end subroutine RR3
end interface
interface ! RR4
    module subroutine RR4(A, B )

[JohnNichols]

I see your point, I wonder what is happening, I have many f90 files that long and they are not slow.  

Interesting and frustrating.   

Sorry old chap, no idea. 

@Barbara === why does your name not pop up in the list of users,  but even on the latest preview it is a dead dog on this code.  

[andrew_4619]

yes John the length of the file is not the trigger  it is the structure of the file. I also not the folds on interface and subroutine often become foobahed  from time to time also which requires closing the solution. Maybe there is linkage....

[JohnNichols]

Edit it in NOTEPAD++ or VEDIT or any decent editor, even SIDEKICK 95. 

[andrew_4619]

Nup, I use Notepad++ for many things but for a large source project actual editing is a small part of the activity,  navigation around the project , links from errors to source file lines etc  the integrated IDE improves productivity in many ways.

[JohnNichols]

Turn off the intellsense

[Devorah_H_Intel]

---

@andrew_4619 wrote:

@Devorah_H_Intel  I created a solution and project attached as a zip slow-ves-edit.f90 is included but not called is is just a generator for the other three source files which consist of a module with 500 interfaces and a submodule with 500 very boring subroutine named rr1 through to rr500. Anyway open the project and have a play and within a vary short period the _if.f90 becomes very slow. Hit enter for a new line and wait a few seconds before you can do the next thing. The more you edit the longer the wait gets. Enjoy.

module slow
implicit none(type, external)
interface ! RR1
    module subroutine RR1(A, B )
        real :: A, B
    end subroutine RR1
end interface
interface ! RR2
    module subroutine RR2(A, B )
        real :: A, B
    end subroutine RR2
end interface
interface ! RR3
    module subroutine RR3(A, B )
        real :: A, B
    end subroutine RR3
end interface
interface ! RR4
    module subroutine RR4(A, B )

---

Thank you @andrew_4619 for putting together the test case for us
I will test and pass it along to engineering for further investigation. 

[Devorah_H_Intel]

---

@andrew_4619 wrote:

@Devorah_H_Intel  I created a solution and project attached as a zip slow-ves-edit.f90 is included but not called is is just a generator for the other three source files which consist of a module with 500 interfaces and a submodule with 500 very boring subroutine named rr1 through to rr500. Anyway open the project and have a play and within a vary short period the _if.f90 becomes very slow. Hit enter for a new line and wait a few seconds before you can do the next thing. The more you edit the longer the wait gets. Enjoy.

module slow
implicit none(type, external)
interface ! RR1
    module subroutine RR1(A, B )
        real :: A, B
    end subroutine RR1
end interface
interface ! RR2
    module subroutine RR2(A, B )
        real :: A, B
    end subroutine RR2
end interface
interface ! RR3
    module subroutine RR3(A, B )
        real :: A, B
    end subroutine RR3
end interface
interface ! RR4
    module subroutine RR4(A, B )

---

Thank you again for the solution. The fix will be available in 2024.1 Intel HPC Toolkit release.

[andrew_4619]

oooooo! Thank you, I will look forward to that update!

This problem does my head in!  I had to restart VS about 10 times yesterday and each time my blood pressure goes up a click !

[JohnNichols]

Breathe, deep breathing and relax.   Feel the Intel Fortran flow though your mind. 

Nirvana awaits you in 3 months or so, you can last that long. 

[Devorah_H_Intel]

@andrew_4619 we are able to reproduce the issue with your reproducer. The engineering team are working on the fix. 

[andrew_4619]

Thanks, I think there used to be several things that caused editor problems and I think some have been fixed / gone away. There may be other issues but with his one a trigger was evident.  I will note that if the reproducer had less routines the problem seems to build up slowly with working and then hit a tipping point where it rapidly becomes unusable.