Performance: Measure plugin overhead to evaluate optimization needs

[genro]

Context

Before implementing architectural changes like wrap_methods parameter (#24), we need to understand the actual performance characteristics of the current plugin system.

Objective

Measure and document plugin overhead to make data-driven decisions about optimization features.

Measurements Needed

1. Baseline Performance

Measure execution time for:

• No decoration: Pure function call
• Decorated, no plugins: Switcher decorator only
• With PydanticPlugin: Type validation overhead
• With LoggingPlugin: Logging overhead (print and log modes)
• With multiple plugins: Combined overhead

2. Scenarios to Test

Simple function (minimal work):

def add(a: int, b: int) -> int:
    return a + b

I/O-bound function (realistic):

def fetch_user(user_id: int) -> dict:
    # Simulated API call (10ms)
    time.sleep(0.01)
    return {'id': user_id, 'name': 'Alice'}

CPU-bound function (computation):

def calculate(data: list[int]) -> int:
    return sum(x ** 2 for x in data)

3. Call Patterns

Test different usage patterns:

• Single call: One-time overhead
• Loop (1000 calls): Amortized cost
• High frequency (100K calls): Hot path scenario

Benchmark Implementation

Create benchmarks/plugin_overhead.py with comprehensive tests.

Success Criteria

After benchmarking, decide:

If overhead is negligible (<10μs per call):

• ✅ Current design is fine
• ✅ Close Feature Request: Optional Method Wrapping (wrap_methods parameter) #24 as won't fix
• ✅ Document acceptable overhead

If overhead is significant (>100μs):

• 🔍 Investigate optimizations
• 🔍 Consider Feature Request: Optional Method Wrapping (wrap_methods parameter) #24 or alternatives

If overhead is moderate (10-100μs):

• 📊 Document tradeoff
• 💡 Recommend best practices
• ❓ Evaluate Feature Request: Optional Method Wrapping (wrap_methods parameter) #24 based on use cases

Expected Outcome

Most likely: Overhead is negligible for I/O-bound operations (API calls, DB queries), which is where SmartSwitch is typically used.

Implementation Tasks

• Create benchmarks/ directory
• Implement plugin_overhead.py benchmark
• Run benchmarks
• Document results
• Make decision on Feature Request: Optional Method Wrapping (wrap_methods parameter) #24
• Update docs with performance guidance

Related Issues

• Feature Request: Optional Method Wrapping (wrap_methods parameter) #24 - Optional Method Wrapping (closed, pending this analysis)

Priority

Medium - Data needed before architectural decisions.

[genro]

Alternative Pattern (No Code Changes Needed)

Before implementing wrap_methods, consider this pattern using existing prefix feature:

class Handler:
    # Switcher strips 'route_' prefix when dispatching
    api = Switcher(prefix='route_').plug('pydantic')
    
    @api
    def route_add(self, x: int, y: int):
        """Validated entry point - called via switcher"""
        return self.add(x, y)
    
    def add(self, x, y):
        """Fast internal method - no validation overhead"""
        return x + y

handler = Handler()

# Via switcher - validated
handler.api('add')(handler, 2, 3)  # → route_add() with plugins

# Direct pythonic - fast
handler.add(2, 3)  # → add() no overhead

Benefits:

• ✅ Uses existing feature (prefix stripping)
• ✅ Explicit and clear (two separate functions)
• ✅ No ambiguity or confusion
• ✅ No new code needed

Recommendation: Document this pattern in FAQ section before implementing new features.