dotnet / dotnet/perf-autofiling-issues
[Perf] Linux/arm64: 1 Improvement on 4/3/2026 5:55:14 PM +00:00
- Dominant language
- No language data
- Stars
- 10
- Forks
- 8
- PR merge metrics
- PR metrics pending
Description
### Run Information
Name | Value
-- | --
Architecture | arm64
OS | ubuntu 22.04
Queue | AmpereUbuntu
Baseline | [34d4f17ce8a8ca3a0f6e09a710323ebe8cbfe13f](https://github.com/dotnet/runtime/commit/34d4f17ce8a8ca3a0f6e09a710323ebe8cbfe13f)
Compare | [950349b9907f5f8c8d56a99223b27e00edfb21f2](https://github.com/dotnet/runtime/commit/950349b9907f5f8c8d56a99223b27e00edfb21f2)
Diff | [Diff](https://github.com/dotnet/runtime/compare/34d4f17ce8a8ca3a0f6e09a710323ebe8cbfe13f...950349b9907f5f8c8d56a99223b27e00edfb21f2)
Configs | CompilationMode:tiered, RunKind:micro
### Improvements in System.Diagnostics.Perf_Process
Benchmark | Baseline | Test | Test/Base | Test Quality | Edge Detector | Baseline IR | Compare IR | IR Ratio
-- | -- | -- | -- | -- | -- | -- | -- | --
|
- [GetCurrentProcessName - Duration of single invocation]()
- 📝 - [Benchmark Source]()
- [ADX - Test Multi Config Graph]()
[Test Report]()
### Repro
General Docs link: https://github.com/dotnet/performance/blob/main/docs/benchmarking-workflow-dotnet-runtime.md
```cmd
git clone https://github.com/dotnet/performance.git
python3 .\performance\scripts\benchmarks_ci.py -f net8.0 --filter 'System.Diagnostics.Perf_Process*'
```
### System.Diagnostics.Perf_Process.GetCurrentProcessName
#### ETL Files
#### Histogram
#### JIT Disasms
### Docs
[Profiling workflow for dotnet/runtime repository](https://github.com/dotnet/performance/blob/master/docs/profiling-workflow-dotnet-runtime.md)
[Benchmarking workflow for dotnet/runtime repository](https://github.com/dotnet/performance/blob/master/docs/benchmarking-workflow-dotnet-runtime.md)
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the referenced benchmark in src/benchmarks/micro/libraries/System.Diagnostics/Perf_Process.cs, especially GetCurrentProcessName, then review the linked test report and comparison commits. Determine whether the reported arm64 improvement is expected and identify the relevant runtime change; done means the result is explained or a specific follow-up is documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, python
- Domain
- performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100