Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Slow editor response

abhimodak
New Contributor I
1,935 Views

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

18 Replies
andrew_4619
Honored Contributor II
1,915 Views

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.

 

0 Kudos
Devorah_H_Intel
Moderator
1,492 Views

@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. 

0 Kudos
JohnNichols
Valued Contributor III
1,484 Views

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. 

0 Kudos
JohnNichols
Valued Contributor III
1,480 Views

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. 

 

0 Kudos
andrew_4619
Honored Contributor II
1,446 Views

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.

0 Kudos
JohnNichols
Valued Contributor III
1,438 Views

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.  

 

0 Kudos
andrew_4619
Honored Contributor II
1,426 Views

andrew_4619_0-1699372933234.png

@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
Valued Contributor III
1,419 Views

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.  

0 Kudos
andrew_4619
Honored Contributor II
1,412 Views

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....

0 Kudos
JohnNichols
Valued Contributor III
1,404 Views

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

0 Kudos
andrew_4619
Honored Contributor II
1,399 Views

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.

0 Kudos
JohnNichols
Valued Contributor III
1,385 Views
0 Kudos
Devorah_H_Intel
Moderator
1,345 Views

@andrew_4619 wrote:

andrew_4619_0-1699372933234.png

@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. 

0 Kudos
Devorah_H_Intel
Moderator
1,032 Views

@andrew_4619 wrote:

andrew_4619_0-1699372933234.png

@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.

0 Kudos
andrew_4619
Honored Contributor II
1,006 Views

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
Valued Contributor III
995 Views

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. 

0 Kudos
Devorah_H_Intel
Moderator
1,327 Views

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

0 Kudos
andrew_4619
Honored Contributor II
1,317 Views

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. 

Reply