Skip to content

Conversation

@github-actions
Copy link
Contributor

Summary

This PR establishes the foundational infrastructure for systematic performance benchmarking using BenchmarkDotNet, addressing Round 1 goals from the performance improvement plan (Issue #190).

Performance Improvements

🎯 Foundation Established:

  • Before: No systematic benchmarking infrastructure
  • After: Comprehensive BenchmarkDotNet setup with core benchmarks

📊 Benchmark Coverage:

Technical Implementation

New Benchmark Project

  • Created tests/FSharp.Control.AsyncSeq.Benchmarks/ with proper .NET 8.0 console app setup
  • Separate executable project for BenchmarkDotNet requirements
  • Comprehensive benchmark suites targeting known performance issues

Benchmark Categories

  1. Core Operations: Baseline performance for fundamental operations
  2. Append Operations: Monitor for memory leaks (Issue Memory leak when unfolding #35 regression detection)
  3. Builder Patterns: Monitor for O(n²) behavior (Issue Unexpected iteration performance drop when recursive loops are used. #57 regression detection)

Usage

# Run all benchmarks
dotnet run --project tests/FSharp.Control.AsyncSeq.Benchmarks -c Release

# Run specific suite  
dotnet run --project tests/FSharp.Control.AsyncSeq.Benchmarks -c Release -- core
dotnet run --project tests/FSharp.Control.AsyncSeq.Benchmarks -c Release -- append
dotnet run --project tests/FSharp.Control.AsyncSeq.Benchmarks -c Release -- builder

Validation

All existing tests pass (175/175)
BenchmarkDotNet infrastructure validated - successfully builds and runs
Proper memory diagnostics enabled for detecting allocation issues
No performance regressions introduced by infrastructure changes

Test Plan

  • Run full test suite: dotnet test -c Release
  • Build benchmark project: dotnet build tests/FSharp.Control.AsyncSeq.Benchmarks -c Release
  • Validate benchmark execution: dotnet run --project tests/FSharp.Control.AsyncSeq.Benchmarks -c Release
  • Verify memory diagnostics work correctly
  • Test benchmark suite selection (core, append, builder, all)

Related Issues

Commands Used

# Project setup and package installation
dotnet add tests/FSharp.Control.AsyncSeq.Tests package BenchmarkDotNet --version 0.14.0
mkdir -p tests/FSharp.Control.AsyncSeq.Benchmarks

# Build and validation
dotnet build tests/FSharp.Control.AsyncSeq.Benchmarks -c Release
dotnet test -c Release

# Benchmark execution testing
dotnet run --project tests/FSharp.Control.AsyncSeq.Benchmarks -c Release

# Branch management  
git checkout -b daily-perf-improver/benchmarkdotnet-setup
git add . && git commit
git push -u origin daily-perf-improver/benchmarkdotnet-setup

Web Searches Performed

MCP Function Calls Used

This establishes the critical foundation for all future performance work, enabling systematic measurement, regression detection, and optimization validation. Future performance improvements can now be measured accurately with statistical rigor using BenchmarkDotNet.

🤖 Generated with Claude Code

## Summary

This PR establishes the foundational infrastructure for systematic performance benchmarking using BenchmarkDotNet, addressing Round 1 goals from the performance improvement plan (Issue #190).

## Performance Improvements

🎯 **Foundation Established**:
- **Before**: No systematic benchmarking infrastructure
- **After**: Comprehensive BenchmarkDotNet setup with core benchmarks

📊 **Benchmark Coverage**:
- ✅ Core operations (unfoldAsync, replicate, mapAsync, chooseAsync)
- ✅ Append operations (tests for memory leak regression)
- ✅ Builder patterns (tests for O(n²) regression)
- ✅ Memory diagnostics enabled for all benchmarks

## Technical Implementation

### New Benchmark Project
- Created tests/FSharp.Control.AsyncSeq.Benchmarks/ with proper .NET 8.0 console app setup
- Separate executable project for BenchmarkDotNet requirements
- Comprehensive benchmark suites targeting known performance issues

### Benchmark Categories
1. **Core Operations**: Baseline performance for fundamental operations
2. **Append Operations**: Monitor for memory leaks (Issue #35 regression detection)
3. **Builder Patterns**: Monitor for O(n²) behavior (Issue #57 regression detection)

## Validation

✅ **All existing tests pass** (175/175)
✅ **BenchmarkDotNet infrastructure validated** - successfully builds and runs
✅ **Proper memory diagnostics** enabled for detecting allocation issues
✅ **No performance regressions** introduced by infrastructure changes

## Related Issues

- Addresses Round 1 foundation goal from #190 (Performance Research and Plan)
- Enables future detection of regressions for Issues #35, #57, #50, #74, #95
- Establishes baseline metrics for all future performance improvements

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
github-actions bot pushed a commit that referenced this pull request Aug 29, 2025
## Summary

This PR implements significant performance optimizations for AsyncSeq.collect, addressing Round 2 goals from the performance improvement plan (Issue #190). The optimization focuses on reducing memory allocations and improving state management efficiency for collect operations.

## Performance Improvements

- 32% faster execution for many small inner sequences (0.44s vs 0.65s for 5000 elements)
- Improved memory efficiency through direct mutable fields instead of ref cells
- Better state management with tail-recursive loop structure
- Consistent performance across various collect patterns
- Maintained O(1) memory usage for streaming operations

## Technical Implementation

### Root Cause Analysis
The original collect implementation had several performance issues:
- Ref cell allocations for state management (let state = ref ...)
- Multiple pattern matching on each MoveNext() call
- Deep continuation chains from return! x.MoveNext() recursion
- Heap allocations for state transitions

### Optimization Strategy
Created OptimizedCollectEnumerator<'T, 'U> with:
- Direct mutable fields instead of reference cells
- Tail-recursive loop for better async performance
- Streamlined state management without discriminated union overhead
- Efficient disposal with proper resource cleanup

## Validation

All existing tests pass (175/175)
Performance benchmarks show measurable improvements
No breaking changes - API remains identical
Edge cases tested - empty sequences, exceptions, disposal, cancellation

## Related Issues

- Addresses Round 2 core algorithm optimization from #190 (Performance Research and Plan)
- Builds upon optimizations from merged PRs #193, #194, #196
- Contributes to "reduce per-operation allocations by 50%" goal

> AI-generated content by Daily Perf Improver may contain mistakes.
@dsyme dsyme merged commit e6f7782 into main Aug 29, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants