- System requirements
- Profiler architecture
- Profiler installation
- Uninstall profiler
- Running the profiler
- Profiler activation
- Welcome screen
- Start profiling
- Profiling overhead
- Snapshots
- Solving performance problems
- CPU profiling
- Thread profiling
- Object allocation profiling
- Memory profiling
- Exception profiling
- Telemetry
- Probes: monitor higher level events
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Automatic deobfuscation
- Summary, automatic deobfuscation
- Filters
- Profiler command line
- Command line tool to control profiling
- Export of profiling results to external formats
- Profiler .NET API
- Profiler HTTP API
- Settings
- Troubleshooting
Group objects by generation
In .NET applications, the garbage collector (GC) plays a significant role in memory management. Understanding how objects are grouped into generations can offer insights into the application's performance and help in optimization.
YourKit .NET Profiler allows you to group objects by their GC generations, and evaluate how much memory they use:
Understanding generations
The .NET garbage collector organizes objects into three primary generations:
1. Generation 0: This generation is the youngest and contains short-lived objects. New objects are created in generation 0. Since the majority of objects are short-lived, only a small percentage of young objects will likely survive their first garbage collection.
2. Generation 1: Medium-lived objects. Once an object survives the first garbage collection, it gets promoted to generation 1. This generation serves as a buffer between short-lived objects and long-lived objects.
3. Generation 2: Long-lived objects. All objects in generation 1 that survive garbage collection are promoted to generation 2. Surviving objects in generation 2 stay in generation 2.
To learn more about the generational garbage collector, please refer to MSDN.
Large object heap allocations
Objects that are 85,000 bytes or larger go straight to the Large Object Heap (LOH), which is a part of generation 2. Limiting such large object allocations can significantly improve performance, because by default this generation is not compacted.