- Overview
- Guides
- Concepts
- Considerations And Constraints
- Absolute File References
- Assembly Colocation Assumptions
- Concurrent Use Of Test Resources
- Cross Application Domain Testing
- Heavily Executed Code Under Test
- Implicit File Dependencies
- Multi Threaded Tests
- Netstandard Test Projects
- Project Atomicity
- Project Build Platform And Configuration
- Rdi Data Point Location
- Test Atomicity
- Unique Test Names
- Using NCrunch With Source Control
- Reference
- Global Configuration
- Overview
- Auto Adjust Clashing Marker Colours
- Build Log Verbosity
- Build Process Memory Limit
- Capabilities Of This Computer
- Coverage Marker Style
- Cpu Cores Assigned To NCrunch Or Ide
- Custom Environment Variables
- Disable Global Hotkey
- Engine Hosting Strategy
- Fast Lane Threads
- Fast Lane Threshold
- Grid Maximum Reconnection Attempts
- Grid Reconnection Delay
- Impact Detection Mode
- Listening Port
- Log To Output Window
- Logging Verbosity
- Marker Colours
- Max Failing Test Trace Log Size
- Max Number Of Processing Threads
- Max Passing Test Trace Log Size
- Max Test Runners To Pool
- NCrunch Tool Window Colors
- Node Id (Name)
- Password
- Performance Aggregation Type
- Performance Display Sensitivity
- Pipeline Optimisation Priority
- Rdi Storage Settings
- Sliding Build Delay
- Snapshot Storage Directory
- Solution Storage Data Limit
- Spinner Colours
- Terminate Test Runners On Complete
- Test Process Memory Limit
- Tests To Execute On This Machine
- Text Output Font
- Workspace Base Path
- Solution Configuration
- Overview
- Additional Files For Grid Processing
- Additional Files To Include
- Allow Parallel Test Execution
- Allow Tests In Parallel With Themselves
- Infer Project References Using Assembly
- Instrumentation Mode
- NCrunch Cache Storage Path
- Only Consider Tests Outofdate If Impacted
- Project Config File Storage Path
- Show Coverage For Tests
- Show Metrics For Tests
- Tests To Execute Automatically
- Project Configuration
- Overview
- Additional Files To Include
- Allow Dynamic Code Contract Checks
- Allow Static Code Contract Checks
- Analyse Line Execution Times
- Autodetect Nuget Build Dependencies
- Build Priority
- Build Process Cpu Architecture
- Build Sdk
- Collect Control Flow During Execution
- Consider Inconclusive Tests As Passing
- Copied Project Dependencies
- Copy Referenced Assemblies To Workspace
- Custom Build Properties
- Data Storage File Size
- Default Test Timeout
- Detect Stack Overflow
- Enable Rdi
- Files Excluded From Auto Build
- Framework Utilisation Types
- Ignore This Component Completely
- Implicit Project Dependencies
- Include Static References In Workspace
- Instrument Output Assembly
- Method Data Limit
- Ms Test Thread Apartment State
- Preload Assembly References
- Prevent Signing Of Assembly
- Proxy Process File Path
- Rdi Cache Size
- Required Capabilities
- Restrict Tostring Usage
- Run Pre Or Post Build Events
- String Length Limit
- Track File Dependencies
- Use Build Configuration
- Use Build Platform
- Use Cpu Architecture
- Runtime Framework
- Overview
- Atomic Attribute
- Category Attribute
- Collect Control Flow Attribute
- Distribute By Capabilities
- Duplicate By Dimensions
- Enable Rdi Attribute
- Environment Class
- Exclusively Uses Attribute
- Inclusively Uses Attribute
- Isolated Attribute
- Method Data Limit Attribute
- Requires Capability Attribute
- Restrict Tostring Attribute
- Serial Attribute
- String Length Limit Attribute
- Timeout Attribute
- Uses Threads Attribute
- Global Configuration
- Troubleshooting
- Tools
- Keyboard Shortcuts
- Manual Installation Instructions
CPU Cores Assigned to NCrunch / CPU Cores Assigned to IDE
Global-level NCrunch configuration settings Default Value: 50% of cores assigned to NCrunch, 50% of cores assigned to your IDE (also controlled by the configuration wizard)ID/Tag in config file: CPUCoresAssignedToNCrunch, CPUCoresAssignedToIDE
Purpose
These two settings control the allocation of CPU resources between NCrunch and your IDE.
To prevent the IDE from being obstructed, NCrunch will lock all of its activity to only be processed by specific CPU cores. This functionality is critical in ensuring that the computer is able to operate efficiently in a state where it is likely to be overloaded with background processing.
Usage
These configuration settings are formatted as comma-delimited lists of CPU core indexes. A computer with 4 logical CPU cores will support the assignment of cores from 0 to 3.
CPU core assignments are handled by logical cores, not physical cores. This means that a hyper-threaded CPU with 4 physical processor cores will be considered as an 8-core system by NCrunch. You should consider this carefully when choosing the split of cores between NCrunch and your IDE, as it is not efficient to have the same physical core being used by both NCrunch and your IDE.
A hyper-threaded CPU with 4 physical cores will typically have its logical cores identified between the physical cores, for example:
| Physical Core | Core 1 | Core 2 | Core 3 | Core 4 |
|---|---|---|---|---|
| Logical Identifiers | 0, 1 | 2, 3 | 4, 5 | 6, 7 |
Recommendations
These settings are much easier to configure using the configuration wizard. When configuring them manually, avoid the following situations:
- A logical CPU core assigned to both VS and NCrunch - This will break the division between VS and NCrunch and could cause NCrunch's background processing to 'steal' important resources from VS intermittently, while also causing less efficient use of the CPU core.
- A physical CPU core assigned to both VS and NCrunch - For the same reasons as above, this is a bad idea. It is very easy to do this accidently, for example, by assigning all 'odd' cores to VS, and all 'even' cores to NCrunch.
- Too few CPU cores assigned to VS - The processing performed by VS is a much higher priority than that performed by NCrunch. If VS lacks sufficient CPU resources, you will experience jerky and/or unresponsive behaviour inside the IDE.
Visual Studio 2010 typically requires at least one physical CPU core in order to operate without interference. When using IDE plugins that perform background tasks (i.e. refactoring tools with solution-wide analysis), it's recommended that you provide Visual Studio with two physical cores if possible.
Visual Studio 2012 and 2013 should always be assigned at least two physical cores where possible.
Visual Studio 2015 should have at least three physical cores where possible.
Visual Studio 2017, 2019 and 2022 seem to require at least four physical cores for optimal performance, but may function with less depending on the size of the solution and how VS has been configured.
