Pure feature request, love the product, etc...

Far and away the most common "configuration" action I perform in NCrunch is to ignore projects. This is because our solutions always seem to be acreting little utilities, etc, which we don't want NCrunch to spend a single cycle or a single byte on supporting.

But it's something of a faff to disable projects:

* Go to "Configuration" (somewhere in the middle of a long menu)
* Decide if you need to be looking at "My Settings" or "Shared Settings" - and accomodate the vague feeling that whichever one you picked might have been the wrong one.
* Find the project (they're grey-on-blue or light-grey-on-blue)
* Find the "Ignore this component completely" option - it's the 4th one down in the 2nd sub-category
* Use a combo box to make a true/false selection (believe me, I sympathise with the motivations for this on the programmer's side, but it's horrible UX...)
[ Chosing to ignore a project now causes NCrunch to restart completely and reload all the other projects.]
* Wait for this restart to settle down and then repeat for the next project you want to ignore

I don't feel I'm special-pleading for my own favourite option here: "ignore completely" is fundamentally different to all the other options (because it supercedes everything else), and I think it should have special treatment, not be buried in among everything else.

So:
* Please could we have something like a checkbox or a right-click option on each project to allow us to ignore it, perhaps even in the "main" NCrunch window (ctrl-shift-m)
* Please could NCrunch not restart when a project is ignored. Just ignore it from that moment on.

Thanks!

Lots, over time - 20, perhaps?
I probably work on 6-8 regularly.
I have three open in different instances of VS at the moment, 5 would probably be the most.



No, it's mostly about ignoring projects which are never going to be relevant - usually utilities which depend on all the libraries in the solution but which are not themselves unit-tested.



It's optimisation - I don't want to see stuff being buit/copied unnecessairly, and NCrunch seems to unroll dependences somehow, so one can see a lot of copies of the same libraries in the working space - presumably because they're depended on by lots of different components? I'm not complaining about that, but I don't want any of it to happen on behalf of a utility I never wanted NC to bother itself with.



I'm not using any colour scheme that I'm aware of. It's possible that it's only the disabled projects that are really grey - maybe the non disabled ones are actually black. The "blue" is a sort of light steel blue - I can't paste an image in here.



That sounds like the effect I want. But the particular solution I'm looking at right now had NCrunch "introduced to it" when you started the company and has been joined at the hip ever since. Since then many, many projects have come and gone (or at least, been unloaded) - many/most of them want to be NCrunched, quite a few don't. There are currently 23 projects in the solution and 7 of them are ignored.




The multiple project thing is helpful and I didn't know that, thanks.

But as for if this is a performance problem: I absolutely 100% consider that copying a project and building it when I didn't want it copied or built is a performance disaster. Every single cycle of CPU, byte of cache-washing and sector of disk used in such an activity is 100% wasted, and if my crappy little utility is dependent on an great big tree of libraries it's going to happen over and over and over again as I work on those libraries. If I'm waiting while NC says "build in progress" and I go and look at the activity queue and see a bunch of projects that are irrelevant in there then I want to stop them being built.

But anyway, it's not a big deal, and I have spent more time writing these two posts than I shall ever spend disabling projects, so I cannot advance a very honest argument about wasted time...

Thanks!

It isn't really, it simply means I have to work evenings and weekends to get any proper work done! I just happen to have worked on several very successful (in their niche) products, and they all need looking after.



VS26 Insiders. I am old and my projects (well, some of them), are old, but my tools are not. I mostly skipped net9 but other than that we always move forward with the framework.



There is no optimisation you can possibly perform that will be better than simple not doing anything with a project, I don't really really feel this should be a point of debate.





I am a busy guy running 5 instances of Visual Studio with Resharper and nCrunch and I buy the fastest, most expensive, computers I can but they run Windows 11. You can be 100% sure that I am in a almost permenant rage about the dreadful performance of all these tools.

But you have now triggered a performance rant, because you say several things which I think hint at why the performance landscape is so terrible on a modern windows box.

* To start gently, I do think it's reasonable for people writing interactive UI to be somewhat cavalier about their users' computer's resources. If you want to take 55ms to respond to a button click rather than 50, then that's fine, and the person who is waiting for you won't notice and won't care.
* All other code effectively runs in the background, and the implied contract between the developer and the user is different, or it should be:
- SSDs are fast, and I bought one because I wanted my computer to be faster, not so that software vendors could spend less effort avoiding disk accesses and thinking (or worse, telling me) it didn't really matter.
- I have lots of memory, but I didn't buy it so that other people can simply waste it.
- I have lots (far too many) of cores of CPU but that doesn't mean people should try and grab them all or stop other people using some of them so that they get a clear run.
- Caching (at every level) is an incredibly important thing for modern processors, but only works if the thing you need is in the cache, and hasn't been washed-out because someone couldn't work out how to make their app sleep until the next weekly firmware update check so they wake up once a second and look at the clock. (This is not a dig at you!)
- My computer is a shared (between software vendors) resource, and I want vendors to behave properly, not each throw their cigarette butts out of the car window and think it doesn't matter because each one is a tiny little bit of cotton and paper.
- To a vendor, his product is the most important thing, but to me it's just a background task which needs to coexist sensibly. Operating system kernels put an enormous amount of effort into that coexistence, but application developers (frequently from the same organisations as the OS) seem hell-bent on subverting that with the biggest land-grab they can make.

But often, it's just laziness or incompetence: at the moment, my PC, which does not have a single IDE open and is basically idle, has an absurd 380 process running on it,and it's doing about 20000 context switches a second, in good part because so many developers have mistaken something being very quick for being something they should do pointlessly over and over again. It seems utterly inescapable - even Zed, which is supposed to be a brand-new on-the-metal high performance editor is doing 250 context switches a second. A backgrounded text editor FFS - would could it possibly be doing other than waiting for a UI event?

When the excellent Bruce Dawson wrote the excellent https://randomascii.word...tage-on-an-idle-laptop/ he said this:



He had to write point 2 because he knows what programmers say when you put point 1 to them.

And if 2016 is too modern, here's one from another 10 years earlier:

https://devblogs.microso...ng/20060124-17/?p=32553

But for "polling" you can substitute "anything which you don't need to do but is just simpler to keep doing anyway", because it all means the same thing in terms of pissing into the public swimming pool.

(I would say that your grid server is very good about not polling when it's idle, so I'll overlook the 2G of RAM it seems to be holding on to :-)

Anyway, I like NCrunch (if not the config dialog) and I admire your tenacity - but you did goad me into the performance stuff :-) As an aside, you may be pleased that I once explained to a group from MS that I wasn't using the VS preview because NCrunch didn't run on it yet, and it didn't run on it yet because you were still massively stinging from a year of being dicked-about by the .net core introduction and couldn't be bothered with playing-along with their time wasting preview process any more. I heard later this has caused quite a reaction internally...

Cheers!

The funny thing about this is that VS2010 was an absolute dog, probably the nadir of the entire VS history. It is a measure of just how bad Windows is nowadays that it can make VS2010 appear in an anecdote about once-great performance.

I agree with you about the cores - there was a great period (at least for those who value multitasking) when we had more cores than individual apps knew how to use. I think the worst laptop I've ever had since the days of single-core machines is a the "22" core one I have now. It just invites build processes to start 22 children each of whom thinks "I'm on a 22 core machine, let's use 22 threads". And before you know where you are you have 22-squared CPU-bound threads doing very little other than context-switching and cache-destruction. And that's just one app. The heterogenous core types make it even more important that the OS deals with this, because no single app has enough information to understand it. Of course the OS product is currently managed by complete morons, so there's little hope there either. I suspect that if the OS lied to every app and told them all they were on a 4 core machine everything would run a lot better.

I see in another thread you're planning to offer some fine-grained threading/CPU control. I predict that will make things worse for most people and you will regret getting involved and wish you'd spent the time on mixed-DPI bugs instead...

Funny you mention that. I'm presently making adjustments to discontinue support for VS versions 2010-2015, because enough is enough.

There are barriers to removing support for old versions of VS, namely in that it involves effort to do it. NCrunch itself has ~26,000 tests, and many of these were written to run on earlier versions of the platform. Most of these tests are still highly relevant, because they examine how the engine behaves under certain conditions, but they still depend on early platforms because at the time they were written, this was the only way to engineer them. So for a full cut, there is a lot of work that needs to be migrated.

I suppose I have the option of just not shipping the installers but keeping the internal integration, but then I receive no benefit from discontinuing support, other than not needing to provide help in this forum for people using older platforms. Since no one using older platforms posts here (because they are so few, and are happy with their situation), there's no advantage to doing this.

So yeah, it's finally happening now. It will make the product lighter and easier to maintain. And as you've stated, earlier versions of NCrunch are still up there and work fine for all those old platforms.