xsharp.eu

Why do you need to restart VS, does that help with comping speed? Or is this a different problem? Or do you mean that it's VS that has become slow and not the compiler? If it's VS that is slow, does it happen while editing, is it slow when typing, when showing member lists, or maybe in some other circumstances?

.

This is what I have noticed: I am compiling a rather large project and I need to wait some seconds for it to compile. Then I am making small changes in a large file (19k LOC in that file) and re-compiling. It works for some iterations, but after A while VS hangs in compilation phase and takes 10-20minutes to finish compilation. That is when I cancel and restart VS. I don't know what is causing this. My guess would be that the file is too big. But I thought that this problem occurred after the last update. Correct me if I am wrong.

Hello Chris, Robert,

When I change something in a lib which is used in other libs and I compile that lib it compiles in VO in a second or so. Then I see a couple of red dots in those libs and main programs. I right click on each of them to compile and about 10 seconds later I am good to go.

The converted VO project is 14 libraries and 1 (big) main program. You almost always need to recompile everything to be able to start the program and you see the counter slowly going up. It takes some extra time to finish, that could be MSBuild. I'd estimate that it counts to 14 in 40 seconds and 15 is another 20.

When Frank starts the program it again shows some Build messages, something I'd say it just finished doing. Why?

Bottom line is that every small change can only be tested in >1 minute while that would cost 2 to 10 seconds in VO, depending where the change is situated in VO. That could easily add 1 hour of waiting time a day compared to VO.

Can't we do something to bring that time back, besides creating a DLL for each lib and maintain it in separate solutions?

Dick

hilberg.it wrote:This is what I have noticed: I am compiling a rather large project and I need to wait some seconds for it to compile. Then I am making small changes in a large file (19k LOC in that file) and re-compiling. It works for some iterations, but after A while VS hangs in compilation phase and takes 10-20minutes to finish compilation. That is when I cancel and restart VS. I don't know what is causing this. My guess would be that the file is too big. But I thought that this problem occurred after the last update. Correct me if I am wrong.

During those 10-20 minutes, can you type in the VS editor? If not, I guess this is a different problem, because the compiler process and Visual Studio are completely separated, a slow compiling should not cause any slowness in VS.

What could make a difference (if it's not a bug in the X# VS integration) though, is if there's not enough available memory and the compiler eats even more, causing then all sorts of problems to the OS. Can you please check when there is this freeze, how much memory is available? And also if there are other programs using extensively the CPU or disk?

.

Dick,

ic2 wrote:
When I change something in a lib which is used in other libs and I compile that lib it compiles in VO in a second or so. Then I see a couple of red dots in those libs and main programs. I right click on each of them to compile and about 10 seconds later I am good to go.

The converted VO project is 14 libraries and 1 (big) main program. You almost always need to recompile everything to be able to start the program and you see the counter slowly going up. It takes some extra time to finish, that could be MSBuild. I'd estimate that it counts to 14 in 40 seconds and 15 is another 20.

When Frank starts the program it again shows some Build messages, something I'd say it just finished doing. Why?

Bottom line is that every small change can only be tested in >1 minute while that would cost 2 to 10 seconds in VO, depending where the change is situated in VO. That could easily add 1 hour of waiting time a day compared to VO.

Can't we do something to bring that time back, besides creating a DLL for each lib and maintain it in separate solutions?

This is not related to the problem that hilberg.it reported.

What you can do to get faster compilation times is to configure Visual Studio to NOT recompile everything, but only the library that was changed.
(Btw: this only works if you are not changing the prototypes of functions/methods and if you are only changing the code inside a function/method)

To do so you need to configure your solution in a special way:
- Make sure that your DLLs have a "fixed" version number (so do not use the "*" character in the version)
- Make sure that all DLLs and the EXE have the same output folder (something like $(Solutiondir)Debug)
- Goto the Build/Configuration manager and remove the checkboxes for the libraries that you do NOT want to be recompiled
- Then apply the change in the DLL and build only that DLL (with Build-Build Selection.
The shortcut for this can be Shift-F^ but may also be different depending on the settings that you have chosen when you started VS for the first time
- Then run the app with Ctrl-F5 or debug the app with F5.
- If you have to compile more than one library you can also select them in the Solution Explorer and build from the context menu.

I know that this is still not as fast as VO, but there is not much we can do about this I am afraid.

Robert

Deselecting Libraries decreases the time the compiler takes, but not by a lot. I can compile my project in 40 seconds instead of a minute now. It is not a lot, but it helps.

I think it is going to be a common practice for me to deselect libraries that don't need to be recompiled.

Hello X#Team,
maybe a hint to solve the problem.
I first installed 2.10 on a system to test it. At first everything worked, at some point I wanted to do a global text replacement. Certainly more than 100 words would have had to be replaced. When the replace was started, it appeared to compile immediately after the first replace. The number of errors kept changing.
I then had to cancel the replacement after 10 minutes and then ran it again in 2.9#. Didn't last a second.

Frank

Chris wrote: During those 10-20 minutes, can you type in the VS editor? If not, I guess this is a different problem, because the compiler process and Visual Studio are completely separated, a slow compiling should not cause any slowness in VS.

What could make a difference (if it's not a bug in the X# VS integration) though, is if there's not enough available memory and the compiler eats even more, causing then all sorts of problems to the OS. Can you please check when there is this freeze, how much memory is available? And also if there are other programs using extensively the CPU or disk?

I notice that VS slows down a lot lately. Don't know what exactly is causing this. CPU/RAM seems to be fine. I can click in VS, but it lacks. I see this banner "We've noticed that extension 'XSharp Visual Studio Project System' is slowing typing performance." Hope that helps.