Studio C Compilation

[Oday Forster]

Everytime I compile using visual studio the rest of my computer crawls because visual studio is hogging all the processors. Is there a way to limit the number of processors that visual studio is using so I can still get some work done during the compilation time?

I found a workaround that actually works for me. Manually restrict affinity for VS process. Open Task Manager, go to Details tab, right click on devenv.exe, select "Set affinity". In the dialog untick several cores. That's it. All spawned cl.exe processes will inherit affinity, and thus won't run on unticked cores.

The /MP option might do it. It limits the number of processes that are spawned when you build a project. So, in your case, you would use it like this /MP1 (/MP[processMax], where processMax is the maximum amount of processes that you want to use).

Another solution that worked for me, BEFORE starting "Build" or "Rebuild", search for "devenv.exe" in task manager, go to details and lower its affinity to fewer cores. (setting affinity of devenv.exe AFTER starting build will not have any effect)

If you're running Windows Vista/7 (possibly XP, but not sure) it's really rather simple.Type in: Control+Shift+Esc to get your taskmanager up.Click on the Processes tabFind the process that needs its processor affinity changedRight-click on the processClick on "Set Affinity"Here you can select which processor(s) your process will use.EDIT: You have to be administrator to get this to work.

I know you can also enter the variables and their addresses into Studio manually and that's OK for small numbers of variables, but when you use structures to store different types calculating the offsets to the fields is tedious and error prone. As I recall if the addresses of the variables changed after program edits Studio would warn you and corrects them to their new addresses

I wish ST would resurrect STM Studio. It is an excellent tool. Anyone with even a modicum of embedded experience can set it up and get results in ten minutes. To use the Monitor you have to spend a couple of hours reading manuals and watching tutorials only to find out at the end that the charting/plotting is useless. That's what I did. Silly me.

Unfortunately I have the same problem that started with the last CubeIDE update (version 1.13.2). Too bad it happened because STMStudio was a very useful tool. I hope someone will come up with a good idea to fix this problem.

To force all compilation units to have the same DWARF version, you must specify the desired DWARF version in your compiler's compiler options. DWARF is a debugging format mainly used in compiling and debugging programs. Here's how to do it: see the 3 screenshots.

I tried it and it works fine now.

Hi, NixOS unstable has bambu-studio packaged for a while. It was broken for a few weeks, but currently it is back working again. If you are on NixOS unstable you can use pkgs.bambu-studio (just tested it).

Due to bambu-studio being a large big C++ codebase with plenty of dependencies, that all have to work in harmony to some extend with the current versions/changes in the nixpkgs repositories - which in particular can be a challenge with mesa and 3D rendering components.

Second(My solution): It happened to me several times, I solved it by returning the studio to a version prior to the orchestrator version, and dependencies versions like UiAutomation ans System.Activities cannot be greater than the orchestrator version either, after that publish from the new Studio old version in order to compile again the dependencies

I have just made my first component made in Integration Studio (for converting a time into it's decimal representation). The component consists out of 1 function with one input and several outputs. I have included a Unit Test project to make sure that the conversion works as expected.

The problem I now have is in regards with these unit tests. When I close Visual Studio 2019 (Enterprise should that matter) and then verify my component from within Integration Studio I get the following error. Since it only lists errors with my UnitTest.cs file I suspect some problem here but since this component compiles successfully in VS I don't see the issue.

Humm. I had just removed the Test project so that I could continue so I tried adding it again. But now Integration Studio is storing the solution files at a very illogical location (a very deep path that I just happened to use in a different editor) and now I'm unable to add project files. I'll try again later and keep you posted.

Every time you load the Visual studio project from integration it stores the project in temp with a guid type of foldername. You can find your last version there, unless you have restarted your windows profile.

When you have more than a few albums of an artist, the artist page becomes a bit cluttered. All Studio, Live and Compilation albums are shown as Main albums. My request is to create separate categories based on the album type and the additional properties that an album can have. Possible categories are:

In terms of the separation between studio and live albums, I can indeed see the value - especially for artists where there is a large number of both. Some users may have a lot of artists like this and others perhaps not so many. Which highlights another aspect of this categorisation system - that perhaps the separation into these categories should be an option for the user, ideally being able to turn on or off each individual category to their liking.

I am fully behind this organizational hierarchy and think it would be a great addition to the software. I have seen @extracampine request this feature many times previously as well so props to you all for staying on this and continuing mention of it!

The free lunch is over and our CPUs are not getting any faster so if you want faster builds then you have to do parallel builds. Visual Studio supports parallel compilation but it is poorly understood and often not even enabled.

Spoiler alert: my test project started out taking about 32 s to build. After turning on parallel builds this dropped to about 22 s. After fixing some configuration errors this further dropped to 8.4 s. Read on if you want the details.

Each source file calculates a Fibonacci value at compile time using a recursive constexpr function so that the 56 byte source files take a second or two to compile. I previously blogged about how to use templates to do slow compiles but the template technique is quite finicky, and the thousands of types that it creates cause other distracting issues, so all of my measurements are done using the constexpr solution (thanks Nicolas).

If we build the debug configuration now we will get an error because Enable Minimal Rebuild is on by default and it is incompatible with multi-processor compilation. We need to turn it off. Again, be sure to select All Configurations and All Platforms before making this change.

The other reason to disable minimal rebuild is because it is not (IMHO) implemented correctly. If you use ccache on Linux then when the cache detects that compilation can be skipped it still emits the same warnings. The VC++ minimal rebuild does not do this, which makes eradicating warnings more difficult.

I wrote a simple program that calls devenv.exe as a sub-process. I also modified my build-tracing batch file to add the /Bt+ flag to the compiler options. This option would frequently crash with VS 2010, but it works reliably with VS 2013 and prints things that look sort of like this:

The pink and green diamonds at the top of the screen shot correspond to the events emitted when my wrapper program sees the /Bt+ output at the end of each compile stage. The mouse is hovering over the circled diamond, and we can read off the payload in the bottom of the tooltip:

The screen shot to the left uses the same horizontal scale as the other ones, but it is so narrow that I can easily fit this paragraph to the right. This paragraph owes its existence to fast parallel compilation, and it would like to say thank you.

Ideally VC++ would emit ETW events at the end of each compilation and linking stage. This would avoid the need for my egregious hacks, and it would give better information, such as which process was working on each file. This would be much better than wrapper processes that use undocumented compile switches. Pretty please?

For another thing, heavily parallel compilation can make your computer slow. A few dozen parallel project builds that are all doing parallel compilation may start up more compiler instances than you have processors, and that may make Outlook a bit less responsive. More on that next week.

I promised at the beginning that my highly artificial test program was representative of real build-time problems that I have addressed. To make that point, here is a compiler lifetime graph from a real project, recorded before I started doing build optimization:

It was doing parallel builds but, due to seven different sets of compilation settings and some serious long-pole compiles it was far from perfectly parallelized. By breaking up some unity files and getting rid of unique compilation settings I was able to reduce the compilation time of this project by about one third.

I bought my laptop three years ago. It has a four-core eight-thread CPU and 8 GB of RAM. I use it for hobby programming projects. For professional programming I would consider that core-count and memory size to be insufficient. Having more cores obviously helps with parallelism, but more memory is also crucial. For one thing you need enough memory to have multiple compiles running simultaneously without paging, but that is just the beginning. You also need enough memory for Windows to use as a disk cache. If you have enough memory then builds should not be significantly I/O bound and you can get full parallelism. My work machine is a six-core twelve-thread CPU with 32 GB of RAM. Adequate. I look forward to the eight-core CPUs coming out later this year, and 64 GB of RAM is probably in my future.

3a8082e126