Hi everyone, I'd like to ask Bitsum developers to add feature that would be very useful for me and many programmers, I think. Sometimes you need to rebuild the whole Visual Studio solution to ensure there are no mistakes. I'd like to make that in background with "Idle" priority for it would be possible to do some other things. The problem is that build process devenv.exe or msbuild.exe creates very-very many helper processes msbuild.exe, cl.exe, link.exe. They are created, do their job, destroy and this repeats. It means you cannot set priority once for, say, cl.exe. OK, you can create a rule that will set all cl.exe and link.exe processes priority to "Idle", but I want to be able to compile my current foreground project with normal priority, but now it's not possible, because it's cl.exe and link.exe processes will apply to the same rule. The most convenient would be set "Idle" priority for the whole devenv.exe or msbuild.exe process tree.
Why not changing the ProBalance from Below Normal to Idle? :)
He desires more control than that.. doesn't want it that way all the time. I am well aware of the problem you face. I feel like there is an eloquent solution here that isn't coming to mind yet, so let me think on this for a bit and get back to you. I am certainly well aware of the problem, especially with VS2012 ;). Speaking of that, which version of VS are you using?
I'm using VS 2010.
ProBalance is not what I exactly want. Let's see how I usually work. I have 2 folders on my filesystem which both contain the same set of source code files of my project. It is convenient, for example, in one such workspace you may be fixing rather isolated bug while in the other you can test vast changes which require rebuilding of the whole solution. I would like to run rebuilding of the whole solution on 2nd workspace but at the same time continue to work with bug on the 1st workspace, and I run compilation there which starts the same msbuild.exe, cl.exe and link.exe processes. I want these processes to run with normal priority and get as much CPU and disk as possible. I'm not sure that ProBalance can distinguish "right" cl.exe and link.exe which will be allowed to run at normal CPU and, especially, I/O priority among about twenty such processes. Though I will try.
Process Lasso *can* distinguish which build tools (cl/msbuild/link/etc..) were launched by which devenv instance, but the issue is it doesn't know the parent process ID before-hand.
However, implementing the logistics into the GUI and core engine is tricky. This honestly may require custom code, which I could add to Process Lasso, unless you can visualize a way that would make this an easy toggle, or easy option to set - something that isn't too obstructive or confusing for the 99.9% of users who wouldn't use it.
I haven't had much time to think more on this, given the work on the watchdog features, then the VC11 switch. However, a simple solution related to the parent process ID feels like it is probably possible, I just haven't visualized how to most simply expose such a feature. Problem is, the PPID is not known before-hand, and using names (devenv.exe in this case), well it matches both :o.
I did, just now, think of one alternate way to approach this.
You could run your builds in two different user contexts.
Now, this is NOT ideal, but it would allow you to use the username in the watchdog rules, or create two distinct sets of configurations (one for each user).
Would it be possible to install your tools to 2 different directories and then use the path in the watchdog rules to make 2 different sets of rules?
Quote from: Hotrod on October 11, 2012, 08:48:58 PM
Would it be possible to install your tools to 2 different directories and then use the path in the watchdog rules to make 2 different sets of rules?
Not in this case because he is talking about Visual Studio. Now, he could use different versions of Visual Studio, but this is not an app he can 'copy around'. It has a very specific, and very referenced, install location. I suppose, in theory, it could be done, but it would take substantial work and creation of some sort of customized platform toolset that referenced different build tools.
That line of thinking, along with my previous comment, leads us to the only present solutions I can conceive of. They are:
- Run one instance as a different user (seems easiest)
- Run one instance in a virtual machine
Remember, rule format is "processname:username" in the user field (tooltip now updated here internally, to be in the next build) ...
Idea with running programs under separate "slow" user is great, I've started using it already, thank you!
Quote from: RomanMe on October 18, 2012, 04:57:03 AM
Idea with running programs under separate "slow" user is great, I've started using it already, thank you!
Glad to be of help ;). If there is one thing I am good at, it is finding 'some other way' to do things ;p.