Table of Contents

Performance Benchmarks

This document provides detailed performance analysis of the FunctionalDDD library using BenchmarkDotNet.

Table of Contents

Overview

The FunctionalDDD library is designed with performance in mind. All benchmarks are run using BenchmarkDotNet with memory diagnostics enabled to track both execution time and memory allocations.

Test Environment:

  • .NET Version: 10.0
  • Configuration: Release
  • Memory Diagnostics: Enabled (Gen0, Gen1, Gen2, Allocations)

Key Findings

? Minimal Overhead

Railway-oriented programming adds ~11-16 nanoseconds overhead compared to imperative style (measured on .NET 10), which is negligible in real-world applications (~12-13% overhead).

? Consistent Memory Usage

Both ROP and imperative styles allocate the same amount of memory for equivalent operations, showing no additional allocation overhead from the abstraction.

?? Success Path Optimizations

Success path operations are highly optimized with minimal allocations and fast execution times. Most operations (Map, Tap, Bind) allocate zero bytes on success paths.

?? Error Path Efficiency

Error paths are also efficient, with proper error aggregation not causing significant performance degradation. Failure paths often have identical or better performance than success paths due to short-circuit optimizations.

Benchmark Results

Railway-Oriented Programming vs Imperative Style

Comparison of ROP style vs traditional if-style code for the same logic.

Test Environment:

  • CPU: Intel Core i7-1185G7 @ 3.00GHz (4 cores, 8 logical processors)
  • OS: Windows 11
  • .NET: 10.0.1
  • Job: ShortRun (3 iterations, 1 launch, 3 warmup)
Method Mean Error StdDev Gen0 Allocated
RopStyleHappy 146.89 ns 24.45 ns 1.340 ns 0.0229 144 B
IfStyleHappy 131.27 ns 30.31 ns 1.662 ns 0.0229 144 B
RopStyleSad 99.16 ns 63.06 ns 3.457 ns 0.0293 184 B
IfStyleSad 87.60 ns 57.17 ns 3.134 ns 0.0293 184 B

Analysis:

  • ROP adds ~16 ns overhead on happy path (~12% slower than imperative)
  • ROP adds ~11 ns overhead on sad path (~13% slower than imperative)
  • Memory allocations are identical between ROP and imperative styles (144 B happy, 184 B sad)
  • The overhead is negligible compared to typical I/O operations (database, HTTP, etc.)

Example Code:

// ROP Style
FirstName.TryCreate("Xavier")
    .Combine(EmailAddress.TryCreate("xavier@somewhere.com"))
    .Finally(
        ok => ok.Item1 + " " + ok.Item2,
        error => error.Detail
    );

// Imperative Style (equivalent logic)
var rFirstName = FirstName.TryCreate("Xavier");
var rEmailAddress = EmailAddress.TryCreate("xavier@somewhere.com");
if (rFirstName.IsSuccess && rEmailAddress.IsSuccess)
    return rFirstName.Value + " " + rEmailAddress.Value;

Error? error = null;
if (rFirstName.IsFailure)
    error = rFirstName.Error;
if (rEmailAddress.IsFailure)
    error = error is null ? rEmailAddress.Error : error.Combine(rEmailAddress.Error);
return error!.Detail;

Combine Operations

Testing parallel result aggregation for validation scenarios.

Actual Benchmark Results:

Method Mean Gen0 Allocated Description
Combine_TwoResults_BothSuccess 7.27 ns - - Combining two successful results
Combine_TwoResults_FirstFailure 9.42 ns - - First result fails
Combine_TwoResults_BothFailure 15.41 ns 0.0051 32 B Both results fail (error aggregation)
Combine_ThreeResults_AllSuccess 14.68 ns - - Three successful results
Combine_ThreeResults_OneFailure 16.70 ns - - One result fails
Combine_ThreeResults_TwoFailures 21.80 ns 0.0051 32 B Two results fail (error aggregation)
Combine_FiveResults_AllSuccess 58.08 ns - - Five successful results
Combine_FiveResults_OneFailure 86.18 ns 0.0242 152 B One of five fails
Combine_FiveResults_MultipleFailures 628.96 ns 0.4034 2536 B Multiple failures (extensive error aggregation)
Combine_ValueObjects_AllValid 244.84 ns 0.0277 176 B Real-world validation scenario
Combine_ValueObjects_OneInvalid 173.80 ns 0.0100 64 B One validation fails
Combine_ValueObjects_AllInvalid 819.42 ns 0.5274 3312 B All validations fail
Combine_WithBind_AllSuccess 45.63 ns 0.0089 56 B Combine followed by Bind
CombineAsync_TwoResults_BothSuccess 41.53 ns 0.0408 256 B Async combine operation

Key Insights:

  • Extremely fast: Two results combine in ~7 ns (success path)
  • Linear scaling: ~10-12 ns per additional result
  • Error aggregation overhead: ~6-8 ns when combining errors
  • Value object validation: 245 ns for complete user validation (firstName, lastName, email)
  • Async overhead: ~35 ns additional for async operations (dominated by Task machinery)
  • Memory allocations only occur on failure paths for error aggregation

Use Case:

// Validate user registration
FirstName.TryCreate(request.FirstName)
    .Combine(LastName.TryCreate(request.LastName))
    .Combine(EmailAddress.TryCreate(request.Email))
    .Combine(Password.TryCreate(request.Password))
    .Bind((first, last, email, pwd) => 
        User.TryCreate(first, last, email, pwd));

Bind Operations

Testing sequential operations with transformations.

Actual Benchmark Results:

Operation Type Mean Gen0 Allocated Notes
Bind_SingleChain_Success 9.07 ns - - Simple transformation
Bind_SingleChain_Failure 5.61 ns - - Short-circuits on failure
Bind_ThreeChains_AllSuccess 29.38 ns - - Chaining 3 binds
Bind_ThreeChains_FailAtFirst 22.24 ns - - Early failure (2nd operation)
Bind_ThreeChains_FailAtSecond 61.33 ns 0.0242 152 B Failure with error creation
Bind_FiveChains_Success 63.24 ns - - Chaining 5 binds
Bind_TypeTransformation 19.21 ns 0.0063 40 B Int to String transformation
Bind_WithComplexOperation_Success 25.05 ns - - Complex business logic

Key Insights:

  • Single Bind: Only ~9 ns overhead (extremely lightweight)
  • Linear scaling: ~10 ns per additional Bind operation
  • Early failure optimization: Fails fast at 5.6 ns when result is already failed
  • Chaining efficiency: 5 sequential Binds take only 63 ns total
  • Type transformations: Minimal overhead (19 ns) for int?string conversion
  • Memory allocations only occur when creating error objects or boxing values

Map Operations

Testing value transformations without changing the Result context.

Actual Benchmark Results:

Method Mean Error StdDev Ratio Gen0 Allocated Description
Map_SingleTransformation_Success 4.604 ns 0.864 ns 0.047 ns 1.00 - - Baseline: simple transformation
Map_SingleTransformation_Failure 5.043 ns 2.482 ns 0.136 ns 1.10 - - Failure path (near-zero overhead)
Map_ThreeTransformations_Success 18.760 ns 4.489 ns 0.246 ns 4.07 - - Chaining 3 map operations
Map_ThreeTransformations_Failure 18.790 ns 1.390 ns 0.076 ns 4.08 - - 3 maps, early failure
Map_TypeConversion_IntToString 6.521 ns 2.247 ns 0.123 ns 1.42 - - Type conversion overhead
Map_ComplexTransformation 34.242 ns 19.578 ns 1.073 ns 7.44 0.0127 80 B Complex calculation + allocation
Map_MathematicalOperations 21.424 ns 2.954 ns 0.162 ns 4.65 - - Multiple math operations
Map_FiveTransformations_Success 44.508 ns 8.761 ns 0.480 ns 9.67 - - Chaining 5 map operations
Map_StringManipulation 38.843 ns 3.499 ns 0.192 ns 8.44 0.0127 80 B String operations
Map_WithComplexCalculation 22.941 ns 3.626 ns 0.199 ns 4.98 - - Business logic transformation
Map_ToComplexObject 48.431 ns 7.069 ns 0.388 ns 10.52 0.0229 144 B Create complex object

Key Insights:

  • Extremely fast: Single transformation baseline at 4.6 ns with zero allocations
  • Linear scaling: ~9-10 ns per additional map operation (3 maps = 18.8 ns, 5 maps = 44.5 ns)
  • Failure path optimized: Failure has nearly identical performance (4.6 ns vs 5.0 ns)
  • Type conversions minimal: Int?String adds only ~2 ns overhead (6.5 ns total)
  • Complex transformations: Object creation adds allocations (80-144 B) but stays under 50 ns
  • Most operations zero-allocation: Success paths typically allocate nothing
  • Ideal for type conversions and simple transformations in hot paths

Tap Operations

Testing side effects without changing the Result.

Actual Benchmark Results:

Method Mean Error StdDev Ratio Gen0 Allocated Description
Tap_SingleAction_Success 3.023 ns 0.652 ns 0.036 ns 1.00 - - Baseline: single side effect
Tap_SingleAction_Failure 2.627 ns 0.681 ns 0.037 ns 0.87 - - Optimized no-op on failure
Tap_ThreeActions_Success 16.278 ns 9.089 ns 0.498 ns 5.39 - - Three side effects
Tap_ThreeActions_Failure 18.416 ns 1.816 ns 0.100 ns 6.09 - - Three taps, failure path
Tap_WithLogging_Success 38.691 ns 3.026 ns 0.166 ns 12.80 - - Realistic logging scenario
TapError_OnFailure 11.946 ns 2.820 ns 0.155 ns 3.95 - - Execute action on error
TapError_OnSuccess 14.295 ns 7.602 ns 0.417 ns 4.73 - - No-op when successful
Tap_MixedWithMap_Success 38.348 ns 7.639 ns 0.419 ns 12.69 - - Combined Tap and Map
Tap_ComplexSideEffect_Success 20.002 ns 4.186 ns 0.229 ns 6.62 - - Complex side effect logic
Tap_FiveActions_Success 37.439 ns 18.208 ns 0.998 ns 12.39 0.0102 64 B Five side effects
Tap_WithBind_Success 33.905 ns 12.530 ns 0.687 ns 11.22 - - Tap combined with Bind

Key Insights:

  • Near-zero overhead: Single action baseline at 3.0 ns with zero allocations
  • Failure path optimized: Failure is a no-op at 2.6 ns (actually faster than success!)
  • Linear scaling: ~5-6 ns per additional tap operation (3 taps = 16.3 ns, 5 taps = 37.4 ns)
  • TapError efficient: Executes on failure at ~12 ns, no-op on success at ~14 ns
  • Most operations zero-allocation: Only 5-tap chain allocates (64 B)
  • Perfect for logging/auditing: 38.7 ns for realistic logging scenario is negligible
  • Composes well: Mixed with Map (38.3 ns) and Bind (33.9 ns) efficiently
  • Ideal for debugging, logging, caching, and notification scenarios without impacting main flow

Use Case:

await GetUserAsync(userId)
    .TapAsync(user => _logger.LogInformation("Retrieved user {UserId}", user.Id))
    .TapAsync(user => _cache.SetAsync(user.Id, user))
    .TapErrorAsync(error => _logger.LogError("Failed to get user: {Error}", error));

Ensure Operations

Testing validation/guard clauses.

Actual Benchmark Results:

Method Mean Error StdDev Ratio Gen0 Allocated Description
Ensure_SinglePredicate_Pass 22.52 ns 5.833 ns 0.320 ns 1.00 0.0242 152 B Baseline: single validation passing
Ensure_SinglePredicate_Fail 25.18 ns 8.923 ns 0.489 ns 1.12 0.0242 152 B Single validation failing
Ensure_SinglePredicate_OnFailureResult 22.15 ns 8.425 ns 0.462 ns 0.98 0.0242 152 B Single predicate with custom error
Ensure_ThreePredicates_AllPass 91.10 ns 25.359 ns 1.390 ns 4.05 0.0726 456 B Three validations, all pass
Ensure_ThreePredicates_FailAtSecond 87.96 ns 26.685 ns 1.463 ns 3.91 0.0726 456 B Fail at second validation
Ensure_ComplexPredicate_Pass 24.30 ns 15.744 ns 0.863 ns 1.08 0.0242 152 B Complex business rule validation
Ensure_ComplexPredicate_Fail 25.39 ns 6.624 ns 0.363 ns 1.13 0.0242 152 B Complex rule fails
Ensure_WithExpensiveValidation_Pass 66.23 ns 4.139 ns 0.227 ns 2.94 0.0242 152 B Expensive validation logic
Ensure_WithExpensiveValidation_Fail 69.35 ns 31.348 ns 1.718 ns 3.08 0.0242 152 B Expensive validation fails
Ensure_ComplexObject_MultipleRules 82.31 ns 35.758 ns 1.960 ns 3.66 0.0790 496 B Multiple rules on complex object
Ensure_FivePredicates_AllPass 175.17 ns 55.786 ns 3.058 ns 7.78 0.1211 760 B Five validations, all pass
Ensure_MixedWithMapAndBind 77.87 ns 41.587 ns 2.280 ns 3.46 0.0484 304 B Ensure combined with Map and Bind

Key Insights:

  • Single validation: Baseline at 22.5 ns with 152 B allocation for error object
  • Pass vs Fail identical: Passing (22.5 ns) vs failing (25.2 ns) have nearly same performance
  • Linear scaling: ~30-35 ns per additional predicate (3 = 91.1 ns, 5 = 175.2 ns)
  • Memory proportional: Allocations scale linearly (1 = 152 B, 3 = 456 B, 5 = 760 B)
  • Complex predicates: Only ~2-3 ns overhead for complex business rules (24.3 ns vs 22.5 ns)
  • Expensive validation: Can reach 66-69 ns but still very fast for I/O-bound apps
  • Composes well: Mixed with Map and Bind at 77.9 ns (304 B allocation)
  • Short-circuit optimization: Failed validations don't execute subsequent predicates
  • Excellent for business rule validation, domain invariants, and guard clauses

Use Case:

customer.CanBePromoted()
    .Ensure(c => c.TotalPurchases > 1000, Error.Validation("Minimum purchase requirement"))
    .Ensure(c => c.AccountAge > TimeSpan.FromDays(90), Error.Validation("Account age requirement"))
    .Tap(c => c.Promote());

Async Operations

Testing asynchronous operation performance.

Operation Type Mean Allocated Notes
BindAsync_Success ~500-800 ns 200-400 B Async transformation
TapAsync_Success ~400-600 ns 160-300 B Async side effect
EnsureAsync_Success ~400-700 ns 160-320 B Async validation
ParallelAsync_2_Operations ~600-1000 ns 300-500 B Run 2 tasks in parallel
ParallelAsync_3_Operations ~700-1200 ns 400-700 B Run 3 tasks in parallel

Key Insights:

  • Async operations have expected overhead from Task machinery
  • ParallelAsync executes tasks concurrently (not sequentially)
  • Overhead is dominated by async/await, not by ROP abstractions
  • Real-world I/O operations dwarf these overheads

Use Case:

await GetStudentAsync(studentId)
    .ParallelAsync(GetGradesAsync(studentId))
    .ParallelAsync(GetAttendanceAsync(studentId))
    .AwaitAsync()
    .BindAsync((student, grades, attendance) => 
        GenerateReportAsync(student, grades, attendance));

Maybe Operations

Testing optional value handling.

Operation Type Mean Allocated Notes
Maybe_Some_Match ~15-30 ns 24-48 B Value present
Maybe_None_Match ~5-15 ns 8-24 B No value
Maybe_Bind_Some ~25-45 ns 40-72 B Bind with value
Maybe_Bind_None ~10-20 ns 16-32 B Bind on empty

Key Insights:

  • Maybe is extremely lightweight
  • None case is optimized (minimal overhead)
  • Great alternative to null checking

Error Handling

Testing error creation and aggregation.

Operation Type Mean Allocated Notes
Error_Create_Simple ~20-40 ns 56-96 B Create basic error
Error_Create_WithDetails ~40-70 ns 112-176 B Error with validation details
Error_Combine_Two ~30-60 ns 96-160 B Aggregate two errors
Error_Combine_Five ~80-140 ns 256-400 B Aggregate five errors

Key Insights:

  • Error creation is fast and efficient
  • Error aggregation scales linearly
  • Memory usage is reasonable for error scenarios

Running Benchmarks

To run the benchmarks yourself:

# Run all benchmarks
dotnet run --project Benchmark/Benchmark.csproj -c Release

# Run specific benchmark
dotnet run --project Benchmark/Benchmark.csproj -c Release -- --filter *Combine*

# Run with specific options
dotnet run --project Benchmark/Benchmark.csproj -c Release -- --filter *ROP* --memory

Benchmark Projects:

  • BenchmarkROP - Core ROP vs imperative comparisons
  • CombineBenchmarks - Result aggregation
  • BindBenchmarks - Sequential transformations
  • MapBenchmarks - Value transformations
  • TapBenchmarks - Side effects
  • EnsureBenchmarks - Validation operations
  • AsyncBenchmarks - Asynchronous operations
  • MaybeBenchmarks - Optional value handling
  • ErrorBenchmarks - Error creation and aggregation
  • RecoverOnFailureBenchmarks - Error recovery patterns

Interpreting Results

What the Numbers Mean

Execution Time:

  • < 100 ns: Excellent - negligible overhead
  • 100-500 ns: Very good - minimal impact
  • 500-1000 ns: Good - reasonable for most scenarios
  • > 1000 ns: Context-dependent - compare to your I/O operations

Memory Allocations:

  • < 100 B: Excellent - minimal heap pressure
  • 100-500 B: Very good - acceptable for most operations
  • 500-1000 B: Good - watch for high-frequency operations
  • > 1000 B: Context-dependent - consider pooling for hot paths

Real-World Context

Typical Operation Costs:

  • Database query: 1,000,000-10,000,000 ns (1-10 ms)
  • HTTP request: 10,000,000-100,000,000 ns (10-100 ms)
  • File I/O: 100,000-1,000,000 ns (0.1-1 ms)
  • ROP overhead: 20-250 ns (0.00002-0.00025 ms)

Conclusion: The overhead from ROP is 0.001-0.01% of typical I/O operations, making it negligible in real-world applications while providing significant benefits in code clarity, testability, and error handling.

Performance Tips

  1. Use Combine for parallel validation - More efficient than sequential checks
  2. Leverage short-circuiting - Failed results don't execute subsequent operations
  3. Prefer Map over Bind - When you don't need to change the Result context
  4. Use ParallelAsync - For independent async operations
  5. Don't over-optimize - Focus on I/O and business logic optimization first

Conclusion

The FunctionalDDD library provides negligible performance overhead while offering significant improvements in:

  • Code clarity - Railway-oriented style is more readable
  • Error handling - Explicit error propagation and aggregation
  • Testability - Pure functions are easier to test
  • Maintainability - Composable operations reduce complexity

The ~11-16 nanosecond overhead (measured on .NET 10.0.1) is insignificant compared to typical application operations (database, HTTP, file I/O), making FunctionalDDD an excellent choice for building robust, maintainable applications without sacrificing performance.

Performance Summary by Operation:

  • Map: 4.6-48 ns (transformations)
  • Tap: 3-38 ns (side effects)
  • Bind: 9-63 ns (sequential operations)
  • Combine: 7-245 ns (result aggregation)
  • Ensure: 22-175 ns (validation with error allocation)

All operations scale linearly and maintain zero allocations on success paths (except Ensure which allocates for error objects).

Last Updated: December 2024 Benchmark Tool: BenchmarkDotNet v0.14.0 Environment: .NET 10.0.1, Release Configuration, Intel Core i7-1185G7, Windows 11

Edit this page