This directory contains comprehensive performance benchmarks for the NINO validator package.

npm run benchmark

Comprehensive benchmarking that includes:

• ✅ Function Performance: All core functions (validate, format, parse, generate)
• 📊 Input Pattern Analysis: Performance comparison across different input types
• 💾 Memory Usage: Memory consumption and leak detection
• 🔄 Bulk Operations: Realistic usage scenarios with large datasets
• 📈 Statistical Analysis: Detailed performance metrics and ratings

Features:

• High-resolution timing using process.hrtime.bigint()
• Memory usage tracking and delta calculation
• Warm-up iterations to ensure accurate measurements
• Performance ratings (Excellent/Good/Poor)
• Comprehensive reporting with insights

npm run benchmark:ci

Lightweight benchmarks suitable for CI/CD pipelines:

• ⚡ Fast Execution: Reduced iteration counts for quick feedback
• 🎯 Performance Gates: Automatic pass/fail based on thresholds
• 📋 Essential Metrics: Core performance indicators only
• 🚀 CI-Friendly: Exits with error codes for automated testing

Thresholds:

• Minimum acceptable: 1,000 operations/second
• Warning threshold: 10,000 operations/second
• Excellent threshold: 100,000 operations/second

npm run benchmark:memory

Enhanced benchmarks with garbage collection control:

• 🧠 Memory Profiling: Detailed memory usage analysis
• 🗑️ GC Control: Manual garbage collection for accurate measurements
• 📊 Memory Leak Detection: Identifies potential memory issues

• Operations/second: How many function calls can be executed per second
• Time per operation: Average time taken for a single function call (in microseconds)
• Memory delta: Memory usage change during benchmark execution

Based on modern Node.js environments:

# Run comprehensive benchmarks
npm run benchmark

# Quick CI-style check
npm run benchmark:ci

# Memory-focused analysis
npm run benchmark:memory

The benchmark:ci script is automatically included in the validate npm script and will run during:

• Pre-publish checks
• CI/CD pipeline validation
• Local validation with npm run validate

The benchmark suite provides automatic insights such as:

• Comparison between valid vs invalid input performance
• Memory efficiency analysis
• Performance consistency across different input patterns

Consider performance investigation if:

• Any function performs below 1,000 ops/sec
• Memory usage grows unexpectedly
• Performance degrades significantly between versions
• CI benchmarks fail consistently

• Valid inputs typically perform faster than invalid ones
• Short-circuit validation can improve invalid input performance
• String operations may be optimized with different approaches
• Random generation performance depends on crypto operations

Uses process.hrtime.bigint() for nanosecond precision timing, ensuring accurate measurements even for very fast operations.

Monitors process.memoryUsage() before and after operations to detect memory leaks and usage patterns.

• Includes warm-up iterations to eliminate JIT compilation effects
• Uses large iteration counts for statistical significance
• Provides multiple metrics (ops/sec, time/op, memory usage)

• Tests various input patterns (valid, invalid, edge cases)
• Includes bulk operations that mirror real-world usage
• Tests string processing scenarios with messy inputs

When adding new benchmarks:

1. Follow the existing pattern for function naming (benchmark[FunctionName])
2. Include appropriate iteration counts for the test type
3. Add both individual and summary reporting
4. Consider memory implications of your tests
5. Update this README with new benchmark descriptions

Benchmarks running slowly:

• Reduce iteration counts in ITERATIONS configuration
• Check for background processes consuming CPU
• Ensure adequate system memory

Inconsistent results:

• Run multiple times and average results
• Check for system load during testing
• Consider using --expose-gc flag for memory tests

CI failures:

• Review performance thresholds in ci-benchmark.js
• Check for environment-specific performance characteristics
• Consider adjusting thresholds for slower CI environments