@jwikman/bc-code-intelligence-mcp 1.5.7-dev.1

package/embedded-knowledge/domains/dean-debug/setloadfields-performance-impact.md

@@ -0,0 +1,70 @@
+---
+title: "SetLoadFields Partial Loading Performance Impact"
+domain: "dean-debug"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["performance", "memory-optimization", "data-loading", "setloadfields"]
+samples: "samples/setloadfields-performance.md"
+---
+
+# SetLoadFields Partial Loading Performance Impact
+
+## Overview
+
+SetLoadFields enables partial record loading in Business Central, fundamentally changing data retrieval from traditional full-record loading to selective field loading. This optimization reduces memory overhead and database I/O by loading only specified fields rather than entire record structures.
+
+**Key Impact**: Performance gains scale with field count differential - loading 3 fields from a 50-field table shows dramatic improvement, while loading 45 fields shows minimal benefit.
+
+## Strategic Framework
+
+### High-Impact Scenarios
+- **Large field count tables** (20+ fields) where only 2-3 fields needed
+- **Blob field tables** (images, documents) when blob data won't be accessed
+- **Batch processing operations** handling large datasets
+- **Cloud environments** where bandwidth optimization is critical
+
+### Low-Impact Scenarios
+- Small tables with few fields
+- Operations requiring most table fields
+- Single-record lookups with minimal field requirements
+
+### Decision Threshold
+Apply SetLoadFields when loading less than 30% of available table fields for meaningful performance gains.
+
+## Architecture Focus
+
+### Memory Optimization Pattern
+SetLoadFields restricts AL's data retrieval to specified fields only, reducing the in-memory footprint proportional to field count reduction. This is particularly effective with tables containing blob fields or wide data structures.
+
+### Query Performance Impact
+Database queries become more efficient through reduced data transfer and faster result set processing. The optimization compounds in batch operations where multiple records are processed.
+
+### Critical Constraint
+Once a record is loaded with SetLoadFields, accessing non-loaded fields triggers automatic reloading of the entire record, potentially negating performance benefits if field access patterns aren't carefully planned.
+
+## Best Practices
+
+### Implementation Strategy
+- **Analyze field usage patterns** before applying SetLoadFields
+- **Group related field access** to minimize reload triggers
+- **Apply consistently** in batch processing scenarios
+- **Monitor performance impact** to validate optimization effectiveness
+
+### Field Selection Approach
+Include all fields that will be accessed during the operation lifecycle to prevent expensive record reloads. Consider both direct field access and indirect access through related functions.
+
+### Batch Operation Optimization
+SetLoadFields provides compound benefits in loops and bulk operations where the memory and I/O savings multiply across record count.
+
+## Anti-Patterns
+
+### Incomplete Field Loading
+Loading a subset of fields only to access additional fields later in the process, triggering expensive full record reloads that eliminate performance gains.
+
+### Overuse in Small Tables
+Applying SetLoadFields to tables with few fields where the optimization overhead exceeds the potential benefits.
+
+### Ignoring Access Patterns
+Implementing SetLoadFields without analyzing actual field usage patterns, leading to frequent reloads and degraded performance.
+
+*Performance measurement samples: see samples/setloadfields-performance.md*

package/embedded-knowledge/domains/dean-debug/setloadfields-performance-optimization.md

@@ -0,0 +1,90 @@
+---
+title: "AL SetLoadFields Performance Optimization"
+domain: "dean-debug"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["performance", "setloadfields", "optimization", "memory", "data-access"]
+samples: "samples/setloadfields-optimization.md"
+type: "performance-pattern"
+category: "optimization"
+pattern_type: "good"
+severity: "medium"
+impact_level: "high"
+improvement_suggestion: "Use SetLoadFields for selective field loading to optimize memory and performance"
+implementation_steps: ["analyze-field-usage", "implement-setloadfields", "measure-performance-impact"]
+validation_criteria: ["memory-reduction", "performance-improvement", "maintained-functionality"]
+technical_areas: ["al-code", "performance"]
+---
+
+# AL SetLoadFields Performance Optimization
+
+## Overview
+
+SetLoadFields enables selective field loading in AL, dramatically reducing memory consumption and improving performance by loading only required fields from database records. This optimization becomes critical when processing large datasets or working with tables containing many fields.
+
+**Performance Impact**: Can reduce memory usage by 70-90% and improve query performance by 50-80% when properly implemented.
+
+**Key Decision**: Use SetLoadFields before any record operations that don't require all table fields.
+
+## Strategic Framework
+
+### When SetLoadFields Delivers Maximum Value
+- **Large table processing** with 20+ fields where only subset needed
+- **Bulk operations** processing thousands of records
+- **Report generation** requiring specific field combinations
+- **Integration scenarios** transferring selective data sets
+- **Memory-constrained environments** where optimization is critical
+
+### Optimal Implementation Patterns
+- **Early Declaration**: Set fields immediately after record variable declaration
+- **Minimal Field Sets**: Load only fields actually used in subsequent operations
+- **Consistent Application**: Apply across entire data access workflow
+- **Documentation Strategy**: Document field selection rationale for maintainability
+
+## Architecture Focus
+
+### Memory Optimization Architecture
+SetLoadFields creates partial record instances containing only specified fields, significantly reducing memory footprint during record processing. The AL runtime optimizes database queries to retrieve only requested fields.
+
+### Data Access Pattern Integration
+- **Query Planning**: Database optimizer uses field specifications for efficient query execution
+- **Network Efficiency**: Reduced data transmission between database and application server
+- **Memory Allocation**: Smaller record instances improve garbage collection performance
+- **Caching Benefits**: More records fit in memory caches due to reduced size
+
+### Performance Monitoring Integration
+Track SetLoadFields effectiveness through telemetry monitoring field loading patterns, memory usage reduction, and query performance improvements.
+
+## Best Practices
+
+### Field Selection Strategy
+- **Usage Analysis**: Profile actual field usage patterns before optimization
+- **Minimal Sets**: Include only fields accessed in subsequent code execution
+- **Primary Key Inclusion**: Always include primary key fields for record identification
+- **Calculated Field Considerations**: Include base fields required for FlowField calculations
+
+### Implementation Patterns
+- **Early Application**: Call SetLoadFields immediately after record declaration
+- **Consistent Scope**: Apply same field set throughout logical operation scope
+- **Update Coordination**: Ensure field sets include all fields modified during updates
+- **Error Handling**: Plan for scenarios where additional fields become necessary
+
+### Performance Validation
+- **Before/After Measurement**: Compare memory and performance metrics with/without optimization
+- **Load Testing**: Validate optimization effectiveness under realistic data volumes
+- **Memory Profiling**: Monitor actual memory usage reduction in production scenarios
+- **Query Analysis**: Verify database query optimization through execution plan analysis
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Over-Optimization**: Applying SetLoadFields for small record sets where overhead exceeds benefits
+- **Incomplete Field Sets**: Missing critical fields causing runtime errors or additional queries
+- **Dynamic Field Requirements**: Using SetLoadFields where field needs vary significantly during execution
+- **Maintenance Complexity**: Creating overly complex field selection logic that's difficult to maintain
+- **Late Application**: Calling SetLoadFields after initial record operations
+- **Inconsistent Usage**: Mixing optimized and non-optimized patterns within same workflow
+- **Primary Key Omission**: Excluding primary key fields breaking record operations
+
+*Implementation examples: see samples/setloadfields-optimization.md*
+*Related patterns: al-performance-optimization.md, memory-management-patterns.md*

package/embedded-knowledge/domains/dean-debug/setloadfields-placement-before-case-statements.md

@@ -0,0 +1,87 @@
+---
+title: "SetLoadFields Placement Before Case Statements"
+domain: "dean-debug"
+difficulty: "advanced"
+bc_versions: "14+"
+tags: ["setloadfields", "case-statements", "conditional-logic", "advanced"]
+prerequisites: ["setloadfields-placement-before-filters", "case-statement-patterns"]
+samples: "samples/setloadfields-before-case.md"
+---
+# SetLoadFields Placement Before Case Statements
+
+## Overview
+
+SetLoadFields placement before CASE statements enables field loading optimization in conditional processing scenarios. When record processing involves multiple execution paths with different field requirements, proper SetLoadFields placement ensures optimal performance across all code paths.
+
+This advanced optimization technique is critical for complex business logic where field usage varies significantly based on record state, business rules, or processing context.
+
+## Conditional Processing Challenge
+
+CASE statements and complex conditional logic create scenarios where different execution paths require different sets of fields. Without careful optimization, developers often load all potentially needed fields upfront, resulting in over-loading and reduced performance.
+
+The challenge is optimizing field loading when you don't know which execution path will be taken until runtime evaluation of record values or business conditions.
+
+## Strategic Placement Benefits
+
+Placing SetLoadFields before CASE statements allows you to:
+- Load common fields needed across multiple execution paths
+- Avoid over-loading fields needed only in specific conditions
+- Maintain performance optimization while supporting complex business logic
+- Create clear separation between data access optimization and business logic
+
+This placement strategy works because SetLoadFields affects subsequent data access operations regardless of the conditional logic that determines which operations are executed.
+
+## Multi-Path Optimization
+
+In scenarios with multiple execution paths, analyze field usage across all possible paths to identify:
+- Common fields needed in all execution paths
+- Path-specific fields needed only in certain conditions
+- Fields that can be conditionally loaded within specific execution paths
+
+Load common fields with the initial SetLoadFields call, then use additional SetLoadFields calls within specific CASE branches for path-specific field loading.
+
+## Performance Impact Analysis
+
+The performance impact varies based on:
+- Number of execution paths in the conditional logic
+- Field overlap between different execution paths
+- Frequency of each execution path in typical usage
+- Size and complexity of fields in each category
+
+Measure performance across different execution paths to validate that the optimization provides benefits in real usage scenarios rather than just theoretical improvements.
+
+## Implementation Strategy
+
+Start with field usage analysis across all CASE statement branches to categorize field requirements. Identify the minimal set of fields needed for the CASE condition evaluation itself, plus any fields commonly used across multiple execution paths.
+
+Place SetLoadFields before the CASE statement with common fields, then add conditional SetLoadFields calls within specific branches for path-specific fields.
+
+## Advanced Pattern Recognition
+
+This optimization pattern applies to various conditional processing scenarios:
+- Status-based processing where different record statuses require different field sets
+- Type-based processing where record types determine field usage patterns
+- Rule-based processing where business rules conditionally access different fields
+- Workflow-based processing where process steps require specific field combinations
+
+## Conditional Field Loading
+
+Within CASE statement branches, use additional SetLoadFields calls to load path-specific fields. This creates a two-tier optimization: common fields loaded upfront, specific fields loaded on demand.
+
+This approach requires careful management to avoid loading fields multiple times or creating unnecessary database round trips for individual field access.
+
+## Error Handling Considerations
+
+When using conditional SetLoadFields within CASE statements, ensure proper error handling for scenarios where field loading fails or records become invalid between the initial load and conditional processing.
+
+Consider the implications of partial field loading on error recovery and debugging scenarios where developers need access to complete record information.
+
+## Performance Monitoring
+
+Monitor the effectiveness of this optimization across different execution paths. Track metrics such as:
+- Field loading efficiency for each CASE branch
+- Memory usage patterns across different execution scenarios
+- Database query performance for conditional field loading
+- Overall processing time improvements
+
+Use this monitoring data to refine the field loading strategy and adjust the balance between common and conditional field loading.

package/embedded-knowledge/domains/dean-debug/setloadfields-placement-before-filters.md

@@ -0,0 +1,70 @@
+---
+title: "SetLoadFields Placement Before Filters"
+domain: "dean-debug"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["setloadfields", "placement", "filters", "order"]
+prerequisites: ["setloadfields-basics", "record-filtering"]
+samples: "samples/setloadfields-before-filters.md"
+---
+# SetLoadFields Placement Before Filters
+
+## Overview
+
+SetLoadFields must be placed before filter operations (SETRANGE, SETFILTER) to be effective. This placement ensures that field loading optimization is applied during the database query execution rather than after records have already been loaded with all fields.
+
+Proper placement is critical for realizing the performance benefits of SetLoadFields optimization. Incorrect placement results in no optimization benefit and can actually reduce performance due to unnecessary function calls.
+
+## Execution Order Impact
+
+When SetLoadFields is placed before filters, BC incorporates the field loading specification into the database query planning. The database query is optimized to retrieve only the specified fields for records matching the filter criteria.
+
+When SetLoadFields is placed after filters, BC has already executed the database query with full field loading. The SetLoadFields call becomes ineffective because the records are already loaded in memory with all fields populated.
+
+## BC Query Processing
+
+BC processes record access operations in a specific sequence:
+1. SetLoadFields specification (if present)
+2. Filter criteria application (SETRANGE, SETFILTER)
+3. Database query execution with optimized field loading
+4. Record iteration (FIND, FINDSET, etc.)
+
+This sequence ensures that field loading optimization is incorporated into the actual database query rather than applied as a post-processing step.
+
+## Performance Implications
+
+Correct placement delivers significant performance benefits:
+- Reduced database I/O for record retrieval
+- Lower memory consumption during record processing
+- Improved query execution speed
+- Better network efficiency between BC service and database
+
+Incorrect placement provides no performance benefit and adds unnecessary processing overhead from the ignored SetLoadFields call.
+
+## Common Placement Errors
+
+The most common error is placing SetLoadFields after SETRANGE or SETFILTER operations. This happens when developers add SetLoadFields optimization to existing code without restructuring the data access logic.
+
+Another common error is placing SetLoadFields immediately before record iteration (FIND, FINDSET) but after filter setup. While this appears logical, it's too late in the execution sequence to provide optimization benefits.
+
+## Verification Techniques
+
+Verify correct placement by reviewing the sequence of your data access operations. SetLoadFields should be the first operation after record variable declaration and before any filter operations.
+
+Use BC performance profiling tools to confirm that field loading optimization is actually taking effect. Properly placed SetLoadFields should show measurable improvements in query execution time and memory usage.
+
+## Code Organization Patterns
+
+Organize your data access code with a consistent pattern:
+1. Record variable declaration
+2. SetLoadFields specification
+3. Filter setup (SETRANGE, SETFILTER)
+4. Record iteration and processing
+
+This pattern ensures correct placement and makes the optimization visible to other developers working with the code.
+
+## Integration with Other Optimizations
+
+Proper SetLoadFields placement is foundational for other field loading optimizations. Primary key optimization, filter field exclusion, and conditional field loading all depend on correct placement before filter operations.
+
+Consider establishing coding standards that require SetLoadFields as the first data access operation after record variable declaration to ensure consistent correct placement across your codebase.

package/embedded-knowledge/domains/dean-debug/setloadfields-primary-key-optimization.md

@@ -0,0 +1,74 @@
+---
+title: "SetLoadFields Primary Key Optimization"
+domain: "dean-debug"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["setloadfields", "primary-key", "memory-optimization"]
+prerequisites: ["record-variables", "primary-key-concepts"]
+samples: "samples/setloadfields-primary-key.md"
+---
+# SetLoadFields Primary Key Optimization
+
+## Overview
+
+SetLoadFields with primary key fields provides the most fundamental memory optimization in BC development. By loading only the primary key fields, you minimize memory usage while maintaining record identity for subsequent operations.
+
+This optimization is particularly effective when you need to pass records between functions, store record references, or perform record existence checks without requiring full record data.
+
+## Core Concept
+
+Primary key optimization leverages BC's ability to uniquely identify records using only key fields. When you specify primary key fields in SetLoadFields, BC loads minimal data while preserving full record functionality for key-based operations.
+
+The optimization works because BC can reconstruct record identity and perform key-based lookups without loading non-key field data into memory. This creates significant performance benefits in scenarios involving large record sets or memory-constrained operations.
+
+## When to Apply
+
+Use primary key optimization when:
+- Passing records between functions where only identity matters
+- Building record reference collections
+- Performing existence checks or validation
+- Processing large datasets where full field loading causes memory pressure
+- Creating temporary record variables for subsequent filtering
+
+Avoid when you need non-key field values immediately after the SetLoadFields call, as this forces additional database round trips.
+
+## Performance Impact
+
+Primary key optimization delivers:
+- Reduced memory consumption (typically 60-80% reduction)
+- Faster record loading from database
+- Lower network traffic between BC service and database
+- Improved garbage collection performance
+- Better scalability with large record volumes
+
+The optimization is most pronounced with tables containing many fields or large field values (text, blob, media fields).
+
+## Implementation Patterns
+
+The basic pattern involves identifying the table's primary key fields and specifying only those fields in the SetLoadFields call. Most BC tables use surrogate keys (single integer field) or composite keys (multiple fields).
+
+For tables with surrogate primary keys, specify the single key field. For tables with composite primary keys, include all fields that comprise the primary key.
+
+## Common Use Cases
+
+**Record Reference Storage**: When maintaining collections of record references where you need identity but not data values.
+
+**Cross-Function Record Passing**: Passing records to functions that will apply their own field loading based on their specific needs.
+
+**Existence Validation**: Checking if records exist without needing their field values.
+
+**Bulk Processing Setup**: Loading minimal record data before applying specific field loading for different processing paths.
+
+## Best Practices
+
+Always identify the correct primary key fields for your target table. Use the table definition or AL development environment to verify key field composition.
+
+Apply primary key optimization early in your data access chain, before other operations that might implicitly load additional fields.
+
+Document your SetLoadFields usage to help other developers understand the optimization strategy and avoid accidentally loading additional fields.
+
+## Integration with Other Optimizations
+
+Primary key optimization combines well with filter placement optimization - apply SetLoadFields with primary keys before setting filters to minimize the data loaded during filter evaluation.
+
+This optimization also supports subsequent field-specific loading where you can add additional fields based on conditional logic or processing requirements.

package/embedded-knowledge/domains/dean-debug/sift-technology-fundamentals.md

@@ -0,0 +1,81 @@
+---
+title: "SIFT Technology Fundamentals"
+domain: "dean-debug"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["sift", "performance", "caching", "optimization", "streaming"]
+prerequisites: ["caching-basics", "database-performance"]
+samples: "samples/sift-technology-fundamentals.md"
+related_topics: ["sift-implementation-patterns", "performance-optimization-workflow"]
+estimated_time: "45 minutes"
+---
+# SIFT Technology Fundamentals
+
+## Overview
+
+SIFT (Streaming In-memory Fast Tables) is Business Central's advanced caching technology that dramatically improves performance for frequently accessed data. SIFT enables real-time aggregation of large datasets without impacting database performance, making it essential for high-performance BC applications.
+
+**Core Value**: SIFT transforms expensive database aggregations into lightning-fast in-memory operations, reducing query times from seconds to milliseconds for summary data.
+
+SIFT maintains pre-calculated totals and counts in memory, automatically updating as underlying data changes. This eliminates the need for expensive GROUP BY operations on large tables during user interactions.
+
+## Strategic Framework
+
+### Use SIFT When
+- **High-frequency aggregations** on tables with >10,000 records
+- **Real-time dashboards** requiring instant summary calculations  
+- **Financial reporting** with complex sum/count operations
+- **Analytics scenarios** with frequent drill-down requirements
+
+### SIFT Architecture Components
+- **SIFT Keys**: Define aggregation dimensions and hierarchy
+- **SIFT Buckets**: In-memory storage for pre-calculated values
+- **Update Triggers**: Automatic maintenance of aggregated data
+- **Query Optimizer**: Intelligent routing of requests to SIFT vs database
+
+### Performance Impact Patterns
+SIFT provides 10-100x performance improvement for aggregation queries but requires memory overhead and maintenance processing. Optimal for read-heavy scenarios with moderate write frequency.
+
+## Implementation Strategy
+
+### SIFT Key Design
+Define SIFT keys based on actual reporting and query patterns, not theoretical needs. Each SIFT key creates memory overhead and maintenance cost.
+
+**Hierarchy Principle**: Structure SIFT keys to support drill-down navigation from high-level summaries to detailed breakdowns.
+
+### Data Volume Considerations
+SIFT becomes cost-effective when table size exceeds 10,000 records and aggregation frequency is high. Below this threshold, database queries may be more efficient.
+
+### Memory Management
+SIFT buckets consume server memory proportional to data cardinality. Monitor memory usage and tune SIFT configurations based on actual system performance.
+
+## Best Practices
+
+### SIFT Key Optimization
+- **Limit SIFT keys** to essential aggregation patterns
+- **Order dimensions** by frequency of use (most common first)
+- **Test with realistic data volumes** before production deployment
+- **Monitor memory consumption** and query performance metrics
+
+### Integration Patterns
+Combine SIFT with appropriate caching strategies for complete performance optimization. Use SIFT for aggregations, standard caching for detailed record access.
+
+### Maintenance Strategy
+SIFT requires regular maintenance windows for optimization. Plan SIFT rebuild operations during low-usage periods to maintain optimal performance.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- Creating SIFT keys for every possible aggregation combination
+- Using SIFT on small tables where database queries are already fast
+- Ignoring memory consumption when designing SIFT hierarchies
+- Deploying SIFT without proper testing on production-scale data
+
+### Common Pitfalls
+- **Over-SIFTing**: Creating too many SIFT keys leads to memory exhaustion
+- **Under-testing**: SIFT behavior differs significantly between small and large datasets
+- **Maintenance neglect**: Failing to schedule regular SIFT optimization operations
+
+*Complete SIFT implementation guide: see SIFT implementation patterns in performance documentation*
+*Memory optimization strategies: see SIFT memory management techniques*
+*Sample implementations: see samples/sift-technology-fundamentals.md*

package/embedded-knowledge/domains/dean-debug/subscriber-singleinstance-performance.md

@@ -0,0 +1,56 @@
+---
+title: "SingleInstance Subscriber Performance Impact"
+domain: "dean-debug"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["events", "singleinstance", "memory", "performance"]
+prerequisites: ["event-subscriber-basics", "memory-management"]
+samples: "samples/singleinstance-subscribers.md"
+---
+# SingleInstance Subscriber Performance Impact
+
+## Overview
+
+SingleInstance subscriber codeunits create one instance per session that persists throughout the session lifecycle. This architectural pattern significantly impacts memory usage and performance characteristics compared to non-SingleInstance subscribers.
+
+The SingleInstance pattern affects three critical performance areas: memory allocation patterns, initialization overhead, and cross-event state management. Understanding these impacts is essential for designing high-performance event-driven BC solutions.
+
+## Memory Allocation Patterns
+
+SingleInstance subscribers consume memory differently than standard subscribers. The codeunit instance remains in memory for the entire session, including all global variables and their allocated memory. This persistence can lead to memory accumulation if not properly managed.
+
+Memory usage grows incrementally with each event processed, particularly when global variables store event data or temporary objects. Large global arrays, complex data structures, or cached references compound memory consumption over long-running sessions.
+
+The session-scoped lifetime means memory is only released when the user session ends, not after individual event processing completes. This pattern requires careful consideration of global variable usage and explicit cleanup strategies.
+
+## Initialization Performance Impact
+
+SingleInstance subscribers incur initialization costs only once per session, during the first event trigger. This front-loaded initialization can improve performance for frequently triggered events but creates unpredictable response times for the initial event.
+
+Heavy initialization logic in SingleInstance subscribers delays the first event response while benefiting subsequent events. The initialization timing becomes critical for user-facing operations where response time consistency matters.
+
+Complex initialization sequences, external service connections, or large data loading operations amplify the first-event delay. Performance testing must account for both cold-start and warm-running scenarios.
+
+## Cross-Event State Management
+
+SingleInstance subscribers can maintain state between event invocations, enabling sophisticated event processing patterns. However, state accumulation introduces performance considerations and potential side effects.
+
+Global variables persisting event data across invocations can create unexpected dependencies between unrelated business operations. State accumulation requires explicit cleanup strategies to prevent memory leaks and logical inconsistencies.
+
+Cross-event state enables powerful optimization patterns like caching frequently accessed data or maintaining connection pools. These optimizations must be balanced against memory usage and state consistency requirements.
+
+## Performance Optimization Strategies
+
+Minimize global variable usage in SingleInstance subscribers to control memory consumption. Use local variables for event-specific data and reserve global variables for truly session-scoped information.
+
+Implement explicit cleanup methods for global variables when appropriate. Consider memory usage patterns and implement cleanup at logical business process boundaries rather than after each event.
+
+Design initialization sequences to be as lightweight as possible while still providing necessary functionality. Defer heavy initialization until actually needed rather than performing all setup during first event processing.
+
+## Common Performance Issues
+
+Memory accumulation from uncleaned global variables leads to session memory growth and potential performance degradation over long sessions. This issue is particularly problematic in high-frequency event scenarios.
+
+Excessive initialization overhead creates inconsistent response times, with the first event significantly slower than subsequent events. This pattern can impact user experience in interactive scenarios.
+
+State management complexity increases debugging difficulty and can introduce performance bottlenecks when cross-event dependencies create processing delays or conflicts.

package/embedded-knowledge/domains/dean-debug/table-event-batch-operation-impact.md

@@ -0,0 +1,66 @@
+---
+title: "Table Event Performance in Batch Operations"
+domain: "dean-debug"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["table-events", "batch-operations", "performance", "optimization"]
+prerequisites: ["table-events-basics", "batch-processing"]
+samples: "samples/table-event-batching.md"
+---
+# Table Event Performance in Batch Operations
+
+## Overview
+
+Table events (OnInsert, OnModify, OnDelete) trigger for every record operation, creating significant performance implications during batch processing scenarios. Understanding event firing patterns and optimization strategies is crucial for maintaining system performance during high-volume operations.
+
+Batch operations that process thousands of records can generate corresponding thousands of event invocations, each potentially executing complex subscriber logic. This multiplication effect can transform efficient batch operations into performance bottlenecks.
+
+Event performance impact varies dramatically based on subscriber complexity, event frequency, and batch size. Proper optimization requires understanding both the business requirements for event processing and the performance characteristics of subscriber implementations.
+
+## Event Firing Patterns
+
+Table events fire synchronously for each record operation, creating a direct correlation between batch size and total event processing time. A batch inserting 1000 records triggers 1000 OnInsert events, each executing all registered subscribers.
+
+Event firing cannot be disabled for individual operations, meaning all batch operations inherit the full event processing overhead. This design ensures data consistency and business rule enforcement but requires careful performance consideration.
+
+Nested batch operations compound event firing, where batch operations triggering additional record operations create cascading event execution. Understanding operation nesting prevents unexpected performance degradation.
+
+## Performance Impact Analysis
+
+Subscriber execution time directly multiplies with batch operation size, making even lightweight subscribers significant performance factors in large batches. A 10ms subscriber becomes a 10-second overhead for 1000-record batches.
+
+Complex subscribers performing database queries, external service calls, or heavy calculations create substantial batch processing delays. The cumulative effect of multiple subscribers amplifies performance impact exponentially.
+
+Memory allocation within subscribers accumulates across batch operations, potentially causing memory pressure during large batch processing. Subscriber memory patterns must consider batch operation contexts.
+
+## Optimization Strategies
+
+Implement conditional logic within subscribers to minimize processing for batch operation contexts. Use system flags or operation context to detect batch scenarios and apply streamlined processing logic.
+
+Defer expensive operations within subscribers when batch processing is detected. Accumulate changes for bulk processing after batch completion rather than processing each record individually.
+
+Consider subscriber architecture patterns that aggregate operations across multiple event invocations, reducing per-event processing overhead through batching within the subscriber logic itself.
+
+## Batch Detection Techniques
+
+System context information can indicate batch operation scenarios, allowing subscribers to adapt their processing logic accordingly. Session information and operation patterns provide batch detection signals.
+
+Operation timing patterns help identify batch scenarios where multiple rapid-fire events suggest bulk processing rather than individual user operations. Time-based detection enables adaptive subscriber behavior.
+
+Custom batch identification mechanisms allow application code to signal batch operations to subscribers, providing explicit control over batch-optimized processing paths.
+
+## Memory Management
+
+Batch operations with table events can create significant memory allocation patterns as subscribers process large numbers of events consecutively. Memory allocation strategies must account for cumulative subscriber memory usage.
+
+Global variables in subscribers accumulate memory across batch operations unless explicitly managed. Batch-aware cleanup strategies prevent memory accumulation during extended batch processing.
+
+Temporary objects created within subscribers should be explicitly disposed when possible to prevent memory pressure during large batch operations.
+
+## Transaction Considerations
+
+Table events execute within the same transaction as the triggering operation, meaning subscriber failures can rollback entire batch operations. Error handling strategies must balance data integrity with batch operation success.
+
+Long-running subscribers can extend transaction duration for batch operations, potentially causing locking issues or transaction timeout failures. Subscriber performance directly affects batch operation transaction management.
+
+Nested transaction scenarios in subscribers require careful consideration during batch operations to prevent deadlocks or transaction conflicts.