perf: Replace internal List for static series

[DaveSkender]

Implements #1259

Note

In looking at 6511517 you can see the difference between the base branch (before) and what this change does (after) for performance. Given the slight variance between GitHub Runners the difference in performance is negligible and unclear -- this may not be something that helps at all. Putting this on hold and will revisit.

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request refactors internal result storage across 70+ indicator StaticSeries files from dynamically-growing List<T> to pre-allocated fixed-size T[] arrays. Each file replaces Add() method calls with indexed assignments results[i] = ..., and converts the final return from the list to new List<T>(results) wrapper. Additionally, the performance documentation is updated with new sections covering series, stream, and buffer indicator benchmarks, latency analysis, and memory considerations.

Possibly related issues

• Issue #1259: This PR implements the exact refactor from List<T>.Add(...) to pre-sized T[] with indexed assignments described in this issue, applied systematically across all StaticSeries indicator implementations.

Possibly related PRs

• PR #1834: Performs the same code-level refactor of static-series indicator implementations, replacing List<T> with pre-sized T[] and changing result population from Add() to indexed assignment with new List<T>(results) return wrapping.

• PR #1469: Related through collection-type handling and FindIndex usage patterns; the main PR switches some indicators to Array.FindIndex while this PR adds a FindIndex extension and updates RemoveWarmupPeriods for similar collection changes.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/m-r/Macd/Macd.StaticSeries.cs (1)

45-45: Add explicit bounds guards before accessing results[i - 1] at lines 45 and 61.

The validation constraints enforce fastPeriods > 0 and slowPeriods > fastPeriods, but do not prevent accessing results[-1] when i = 0:

• Line 45: When fastPeriods = 1 and i = 0, the condition 0 >= 0 is true, leading to results[-1] access.
• Line 61: When slowPeriods = 2 and signalPeriods = 0 (both allowed by validation), the condition i >= 0 is true at i = 0, leading to results[-1] access.

Line 51 is safe because slowPeriods > fastPeriods ensures slowPeriods ≥ 2, so the condition i >= slowPeriods - 1 requires i ≥ 1.

Line 64–67 (loop accessing results[p]) is safe because it only executes when line 61's condition is true, which implicitly ensures i ≥ signalPeriods + slowPeriods - 2 ≥ 0.

Fix: Add i > 0 && guard before the second condition at lines 45 and 61, or raise the minimum fastPeriods and slowPeriods constraints to 2 and 3 respectively.

🧹 Nitpick comments (11)

src/m-r/Mfi/Mfi.StaticSeries.cs (1)

78-88: Consider sliding window optimization for O(n) complexity.

The nested loop recalculates the sum of positive and negative money flows from scratch each period, resulting in O(n × lookbackPeriods) complexity. A sliding window approach could maintain running sums and update them incrementally (subtract exiting period, add entering period) to achieve O(n) complexity.

This optimization is outside the scope of the current List-to-array refactor but would align with the guideline to "implement single-pass O(n) algorithms."

src/e-k/Fractal/Fractal.StaticSeries.cs (1)

46-46: Excellent performance optimization!

The change from List<FractalResult> to pre-allocated FractalResult[] eliminates dynamic list resizing during the loop, reducing allocations in the hot path. This aligns perfectly with the "Performance First" principle and the guideline to minimize allocations in loops.

The pattern is correct:

• Pre-sizes the array to exact capacity (length)
• Uses index assignment instead of Add()
• Wraps the populated array in a List<FractalResult> at return

This optimization is consistent with the same refactor applied across other indicators (Obv, ElderRay, Cci, Keltner, etc.).

---

Optional: Consider returning the array directly for zero-copy performance.

For an even further optimization in a future refactor, you could return results directly since FractalResult[] implements IReadOnlyList<FractalResult>. This would eliminate the final copy operation when constructing new List<FractalResult>(results). However, this may have API implications (mutability, compatibility with existing consumers), so the current approach of wrapping in List is a reasonable and safe choice.

🔎 Potential future optimization

-        return new List<FractalResult>(results);
+        return results;

Note: Only consider this if the API design allows returning arrays directly without breaking consumer expectations.

Based on learnings, "Allocate only result list and minimal working buffers; avoid temporary per-step Lists or LINQ in loops."

Also applies to: 108-114

src/e-k/Kama/Kama.StaticSeries.cs (1)

99-99: Consider Array.AsReadOnly to avoid the final copy.

The current implementation copies the entire array into a new List<KamaResult>. Using Array.AsReadOnly(results) would wrap the array without copying, further improving performance while satisfying the IReadOnlyList<KamaResult> return type.

🔎 Proposed optimization

-        return new List<KamaResult>(results);
+        return Array.AsReadOnly(results);

Note: If this pattern is applied across the 70+ files mentioned in the PR summary, consider applying this optimization consistently.

src/m-r/Obv/Obv.StaticSeries.cs (1)

48-48: Consider eliminating the final array→List copy.

The new List<ObvResult>(results) constructor copies the entire array. Since the public API returns IReadOnlyList<ObvResult> and arrays implement IReadOnlyList<T>, you could avoid this copy by:

1. Changing the CalcObv return type to IReadOnlyList<ObvResult>
2. Returning the array directly: return results;

This would eliminate one full data copy, though it depends on whether internal code relies on the mutable List return type. Given this is a systematic change across 70+ indicators, evaluate whether this refinement is feasible project-wide.

src/a-d/Dynamic/Dynamic.StaticSeries.cs (1)

51-51: Consider Array.AsReadOnly() to eliminate the final array copy.

The current implementation copies the array into a new List. Since the return type is IReadOnlyList<DynamicResult>, you could use Array.AsReadOnly(results) to return a zero-copy wrapper instead.

This eliminates one allocation and copy operation while maintaining proper encapsulation and the read-only contract.

🔎 Proposed optimization

-        return new List<DynamicResult>(results);
+        return Array.AsReadOnly(results);

Note: This optimization would apply across all 70+ indicator files using this pattern, amplifying the performance benefit.

src/e-k/Ichimoku/Ichimoku.StaticSeries.cs (1)

139-139: Consider returning the array directly to avoid the final copy.

Since arrays implement IReadOnlyList<T>, you could return results directly instead of wrapping it in a new List, eliminating the O(n) copy operation:

-return new List<IchimokuResult>(results);
+return results;

However, the current pattern is applied consistently across 70+ files in this PR and may be intentional for defensive immutability or to ensure consistent collection behavior. The net performance benefit is still positive given the elimination of List resizing during the loop.

src/s-z/Wma/Wma.StaticSeries.cs (1)

56-56: Consider returning the array directly to eliminate the final allocation.

Since WmaResult[] implements IReadOnlyList<WmaResult>, you could return results directly instead of wrapping it in a new List. This would eliminate the final allocation entirely:

-        return new List<WmaResult>(results);
+        return results;

However, I notice this wrapping pattern is consistent across all StaticSeries implementations in this PR (Obv, ElderRay, etc.), suggesting it may be intentional for consistency or other design considerations.

src/e-k/Keltner/Keltner.StaticSeries.cs (1)

81-81: Consider returning the array directly for further optimization.

Since the project targets .NET 8+ and the return type is IReadOnlyList<KeltnerResult>, you could return the array directly without the List wrapper, eliminating the final copy operation:

return results;

This would reduce allocations from 2 to 1. However, wrapping in List may be intentional for defensive copying or consistency with the library's design patterns.

🔎 Proposed optimization

-        return new List<KeltnerResult>(results);
+        return results;

src/s-z/Stc/Stc.StaticSeries.cs (1)

33-41: Optional: Consider future optimization of LINQ chain.

The .Select(...).ToList().CalcStoch(...) chain creates a temporary List<QuoteD> allocation. If further optimizing this hot path, consider whether CalcStoch could accept a span or array directly.

This is a pre-existing pattern, not introduced by this PR, so it's noted as an optional future enhancement rather than a blocking concern.

src/m-r/Roc/Roc.StaticSeries.cs (1)

25-25: LGTM! Optimization pattern correctly applied.

The array-based result accumulation is correctly implemented with proper indexed assignment and final List conversion. This completes the consistent pattern across all reviewed files, delivering allocation reduction in accordance with performance-first principles.

Optional: Consider direct array return for further optimization.

Across the PR, private Calc* methods currently wrap the array in new List<T>(results), which performs an O(n) copy. Since arrays implement IReadOnlyList<T>, you could eliminate this final allocation by either:

1. Changing private method signatures to return IReadOnlyList<T> and returning the array directly, or
2. Returning the array and letting the public method handle any necessary wrapping.

This would eliminate one allocation per indicator call, though the current approach is already a significant improvement and maintains clearer type semantics. This optimization would be most impactful for high-frequency calculations with realistic data sizes (e.g., 502 periods as noted in learnings).

Based on learnings: "Optimize hot paths: minimize allocations, avoid excessive LINQ, use Span where appropriate."

Also applies to: 51-54, 57-57

src/a-d/Beta/Beta.StaticSeries.cs (1)

145-159: Optional: Consider array pre-allocation in CalcBetaWindow.

Lines 145-146 still use dynamic List<double> with Add() in the loop. While the performance impact is lower since this method operates per-window rather than per-data-point, pre-allocating arrays would be more consistent with the optimization pattern.

🔎 Proposed refactor to use arrays

-        List<double> dataA = new(lookbackPeriods);
-        List<double> dataB = new(lookbackPeriods);
+        double[] dataA = new double[lookbackPeriods];
+        double[] dataB = new double[lookbackPeriods];
+        int count = 0;

         for (int p = i - lookbackPeriods + 1; p <= i; p++)
         {
             double a = mrktReturns[p];
             double b = evalReturns[p];

             if (type is BetaType.Standard
             || (type is BetaType.Down && a < 0)
             || (type is BetaType.Up && a > 0))
             {
-                dataA.Add(a);
-                dataB.Add(b);
+                dataA[count] = a;
+                dataB[count] = b;
+                count++;
             }
         }

-        if (dataA.Count == 0)
+        if (count == 0)
         {
             return beta;
         }

         // calculate correlation, covariance, and variance
         CorrResult c = Correlation.PeriodCorrelation(
             default,
-            [.. dataA],
-            [.. dataB]);
+            dataA.AsSpan(0, count).ToArray(),
+            dataB.AsSpan(0, count).ToArray());

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

docs/pages/performance.md (1)

539-540: Correct .NET version inconsistency in benchmarking notes.

Line 539 states ".NET 9.0.0" but all environment blocks (lines 18-405) specify ".NET 10.0.1". Verify which version was actually used and update line 539 for consistency. If this is intentional (e.g., legacy note), add clarification.

🧹 Nitpick comments (1)

docs/pages/performance.md (1)

441-447: Clarify whether performance profile examples are illustrative or representative.

Lines 442-447 show example timing (Series ~25μs, BufferList ~30μs) that don't correspond to actual indicators in the benchmark tables above. Specify whether these are:

• Illustrative averages across all indicators
• Specific to certain indicator types
• Outdated from prior benchmark runs

This improves clarity for readers comparing expected vs. actual performance.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e199723 and 6511517.

📒 Files selected for processing (1)

• docs/pages/performance.md

🧰 Additional context used

📓 Path-based instructions (6)

docs/**/*.md

📄 CodeRabbit inference engine (.github/instructions/docs.instructions.md)

docs/**/*.md: Follow markdown linting rules in the .github/instructions/markdown.instructions.md file
Ensure YAML front matter follows documented schema
Include required YAML front matter for all documentation pages
Use consistent layout references in Jekyll front matter
Set appropriate page titles and descriptions in Jekyll front matter
Include navigation metadata in front matter when applicable
Document version-specific features appropriately
Provide migration guidance for breaking changes in documentation

Follow documentation site development guidance defined in docs/AGENTS.md for Jekyll documentation site authoring.

Files:

• docs/pages/performance.md

---

⚙️ CodeRabbit configuration file

docs/**/*.md: Check for:

• Accuracy: Ensure content matches current implementation
• Completeness: Verify examples, parameters, and return values are documented
• Accessibility: Flag missing alt text, poor heading hierarchy
• Link validity: Check for broken internal/external links
• Mathematical formulas: Verify calculation descriptions are correct

Files:

• docs/pages/performance.md

docs/**/*.{html,md}

📄 CodeRabbit inference engine (.github/instructions/docs.instructions.md)

Use semantic HTML elements when HTML is required

Files:

• docs/pages/performance.md

docs/**/*.{md,html}

📄 CodeRabbit inference engine (.github/instructions/docs.instructions.md)

docs/**/*.{md,html}: Provide alt text for all images
Ensure proper heading hierarchy with no skipping levels
Include descriptive link text and avoid 'click here' phrases
Verify all internal and external links work in documentation
Check for typos and formatting consistency in documentation changes
Maintain accuracy of mathematical formulas and calculations in documentation
Clearly mark deprecated features in documentation

Files:

• docs/pages/performance.md

docs/**

📄 CodeRabbit inference engine (.github/instructions/docs.instructions.md)

Build Jekyll documentation without errors before committing changes

Files:

• docs/pages/performance.md

docs/**/*.{md,yml,yaml}

📄 CodeRabbit inference engine (.github/instructions/docs.instructions.md)

docs/**/*.{md,yml,yaml}: Update examples and documentation when API changes occur
Maintain backward compatibility in examples where possible

Files:

• docs/pages/performance.md

**/*.md

📄 CodeRabbit inference engine (.github/instructions/markdown.instructions.md)

**/*.md: Convert title case in headers to sentence case (capitalize first word and proper nouns only)
Convert title case in bold labels to sentence case (capitalize first word and proper nouns only)
Replace asterisk (*) and plus (+) bullets with hyphens (-)
Convert Setext headers (===, ---) to ATX headers (#, ##, ###)
Add blank lines before and after headers
Add blank lines before and after code block fences
Do not use backticks in #file: references; use plain format #file:path
Convert ordered lists to unordered hyphen lists when items are not sequential
Remove trailing punctuation after #file: or #tool: tokens
Add language identifier to all fenced code blocks (use plaintext when language is unknown)
Use outer fence length greater than inner fence length for nested code blocks (e.g., 5 backticks for outer, 3 for inner)
Use present tense and imperative mood in Markdown content (e.g., 'Run the command' not 'You should run')
Use sentence case only for headers (capitalize first word and proper nouns; lowercase articles, prepositions, conjunctions)
Use ATX style headers only (#, ##, ###); never use Setext style (===, ---)
Add blank lines before and after all headers
Maintain sequential header hierarchy without skipping levels (# → ## → ###)
Use hyphens (-) for all bullet points; never use asterisks (*) or plus signs (+)
Indent nested lists with exactly two spaces
Use ordered lists (1., 2., 3.) only when sequence matters; otherwise use unordered hyphen lists
Use fenced code blocks only (```); never use indented code blocks
Include language identifier on all code fences; use plaintext when language is unknown
Add blank line before and after code block fences
Do not wrap #file: or #folder: or #tool: tokens in backticks; use plain syntax
Do not place punctuation immediately after #file:, #folder:, or #tool: tokens
Use #tool: syntax only for VS Code Copilot Chat built-in tools (search, edit, read, `ru...

Files:

• docs/pages/performance.md

🧠 Learnings (14)

📓 Common learnings

Learnt from: DaveSkender
Repo: DaveSkender/Stock.Indicators PR: 1838
File: .editorconfig:140-141
Timestamp: 2026-01-03T03:54:03.646Z
Learning: Applies to src/**/*.StaticSeries.cs: Prefer `new List<T>(array)` over collection expressions `[..array]` when returning results from indicator calculations. The constructor pattern guarantees single allocation and bulk copy, which is safer for performance-critical hot paths. IDE0305/IDE0306 suppressions are appropriate for this use case.

Learnt from: DaveSkender
Repo: DaveSkender/Stock.Indicators PR: 1471
File: tests/indicators/s-z/Tsi/Tsi.StreamHub.Tests.cs:84-247
Timestamp: 2025-10-03T17:49:24.747Z
Learning: Static series implementations are the canonical reference for indicators, aligned to original reputable author formulas linked in documentation. Buffer lists and stream hubs must match static series exactly.

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: src/AGENTS.md:0-0
Timestamp: 2026-01-01T06:10:39.651Z
Learning: Applies to src/tools/performance/**/*.cs : Add performance benchmarks with default case to the appropriate file in `tools/performance` (Series/Stream/Buffer)

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: .github/instructions/performance-testing.instructions.md:0-0
Timestamp: 2025-10-01T07:32:55.702Z
Learning: Optimize hot paths: minimize allocations, avoid excessive LINQ, use Span<T> where appropriate, cache calculations, and test with realistic data sizes (502 periods)

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: src/AGENTS.md:0-0
Timestamp: 2026-01-01T06:10:39.651Z
Learning: Series indicators are the canonical source of truth for numerical correctness; Stream and Buffer implementations must match Series results for the same inputs once warmed up

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: .github/instructions/performance-testing.instructions.md:0-0
Timestamp: 2025-10-01T07:32:55.702Z
Learning: Applies to tests/performance/**/Perf.Series.cs : Name series-style benchmark files Perf.Series.cs

Learnt from: DaveSkender
Repo: DaveSkender/Stock.Indicators PR: 1471
File: tests/indicators/s-z/Tsi/Tsi.StreamHub.Tests.cs:84-247
Timestamp: 2025-10-03T17:49:24.747Z
Learning: All indicator implementation styles (static series, buffer lists, stream hubs) must be mathematically equivalent and produce identical results when given the same parameters and data. Any drift between implementations indicates a source code error, not acceptable floating-point variance.

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: src/AGENTS.md:0-0
Timestamp: 2026-01-01T06:10:39.651Z
Learning: Applies to src/tools/performance/**/*.cs : Include performance tests for computationally intensive indicators

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-01-03T00:10:13.974Z
Learning: Applies to **/*.cs : Performance First is a critical consideration for all indicator implementations and computational routines.

Learnt from: DaveSkender
Repo: DaveSkender/Stock.Indicators PR: 1406
File: .github/copilot-instructions.md:37-55
Timestamp: 2025-09-28T22:37:53.272Z
Learning: For the Stock Indicators repository: Use double for performance in iterative indicator calculations, then promote to decimal when exposing price-sensitive or monetary results that require trading accuracy. The canonical numeric precision policy is documented in .github/instructions/source-code-completion.instructions.md and referenced in spec-kit integration guide.

📚 Learning: 2026-01-01T06:10:39.651Z

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: src/AGENTS.md:0-0
Timestamp: 2026-01-01T06:10:39.651Z
Learning: Applies to src/tools/performance/**/*.cs : Add performance benchmarks with default case to the appropriate file in `tools/performance` (Series/Stream/Buffer)

Applied to files:

• docs/pages/performance.md

📚 Learning: 2025-10-01T07:32:55.702Z

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: .github/instructions/performance-testing.instructions.md:0-0
Timestamp: 2025-10-01T07:32:55.702Z
Learning: Applies to tests/performance/**/Perf.Series.cs : Name series-style benchmark files Perf.Series.cs

Applied to files:

• docs/pages/performance.md

📚 Learning: 2025-10-01T07:32:55.702Z

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: .github/instructions/performance-testing.instructions.md:0-0
Timestamp: 2025-10-01T07:32:55.702Z
Learning: Applies to tests/performance/**/BenchmarkConfig.cs : Keep BenchmarkConfig.cs as the single source of benchmark configuration (exporters: GitHub markdown and JSON; columns: Mean, Error, StdDev; logger: Console) and do not modify without maintainer approval

Applied to files:

• docs/pages/performance.md

📚 Learning: 2025-10-01T07:32:55.702Z

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: .github/instructions/performance-testing.instructions.md:0-0
Timestamp: 2025-10-01T07:32:55.702Z
Learning: Applies to tests/performance/**/Perf.Stream.cs : Name stream-style benchmark files Perf.Stream.cs

Applied to files:

• docs/pages/performance.md

📚 Learning: 2025-10-01T07:32:55.702Z

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: .github/instructions/performance-testing.instructions.md:0-0
Timestamp: 2025-10-01T07:32:55.702Z
Learning: Applies to tests/performance/**/Perf.StyleComparison.cs : Name style-comparison benchmark files Perf.StyleComparison.cs

Applied to files:

• docs/pages/performance.md

📚 Learning: 2026-01-01T06:10:39.651Z

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: src/AGENTS.md:0-0
Timestamp: 2026-01-01T06:10:39.651Z
Learning: Applies to src/**/MigrationGuide.V3.md : Update `MigrationGuide.V3.md` with migration notes and bridges when behavior changes

Applied to files:

• docs/pages/performance.md

📚 Learning: 2026-01-01T06:10:39.651Z

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: src/AGENTS.md:0-0
Timestamp: 2026-01-01T06:10:39.651Z
Learning: Applies to src/**/*Obsolete.V3*.cs : Update migration bridges in `Obsolete.V3.Indicators.cs` and `Obsolete.V3.Other.cs` to reflect new/renamed APIs or deprecations

Applied to files:

• docs/pages/performance.md

📚 Learning: 2026-01-01T06:10:39.651Z

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: src/AGENTS.md:0-0
Timestamp: 2026-01-01T06:10:39.651Z
Learning: Applies to src/tools/performance/**/*.cs : Include performance tests for computationally intensive indicators

Applied to files:

• docs/pages/performance.md

📚 Learning: 2025-10-01T07:32:55.702Z

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: .github/instructions/performance-testing.instructions.md:0-0
Timestamp: 2025-10-01T07:32:55.702Z
Learning: Profile before optimizing; run benchmarks incrementally and document significant performance improvements in PRs

Applied to files:

• docs/pages/performance.md

📚 Learning: 2025-10-01T07:32:55.702Z

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: .github/instructions/performance-testing.instructions.md:0-0
Timestamp: 2025-10-01T07:32:55.702Z
Learning: Applies to tests/performance/**/Perf.Buffer.cs : Name buffer-style benchmark files Perf.Buffer.cs

Applied to files:

• docs/pages/performance.md

📚 Learning: 2025-10-03T17:49:24.747Z

Learnt from: DaveSkender
Repo: DaveSkender/Stock.Indicators PR: 1471
File: tests/indicators/s-z/Tsi/Tsi.StreamHub.Tests.cs:84-247
Timestamp: 2025-10-03T17:49:24.747Z
Learning: Static series implementations are the canonical reference for indicators, aligned to original reputable author formulas linked in documentation. Buffer lists and stream hubs must match static series exactly.

Applied to files:

• docs/pages/performance.md

📚 Learning: 2026-01-01T06:10:39.651Z

Learnt from: CR
Repo: DaveSkender/Stock.Indicators PR: 0
File: src/AGENTS.md:0-0
Timestamp: 2026-01-01T06:10:39.651Z
Learning: Series indicators are the canonical source of truth for numerical correctness; Stream and Buffer implementations must match Series results for the same inputs once warmed up

Applied to files:

• docs/pages/performance.md

📚 Learning: 2025-10-03T17:49:24.747Z

Learnt from: DaveSkender
Repo: DaveSkender/Stock.Indicators PR: 1471
File: tests/indicators/s-z/Tsi/Tsi.StreamHub.Tests.cs:84-247
Timestamp: 2025-10-03T17:49:24.747Z
Learning: All indicator implementation styles (static series, buffer lists, stream hubs) must be mathematically equivalent and produce identical results when given the same parameters and data. Any drift between implementations indicates a source code error, not acceptable floating-point variance.

Applied to files:

• docs/pages/performance.md

⏰ Context from checks skipped due to timeout of 400000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Codacy Static Code Analysis

🔇 Additional comments (1)

docs/pages/performance.md (1)

424-428: Verify performance overhead percentages against actual benchmark data.

The Performance Comparison table claims BufferList "~10-20% overhead" and StreamHub "~20-30% overhead", but actual benchmark data shows much higher variance. For example:

• ToAdx: BufferList 146% overhead, StreamHub 230% overhead
• ToEma: BufferList 32% overhead, StreamHub 500% overhead

Clarify whether these percentages represent averages across all indicators, apply only to simple/fast indicators, or need revision. Consider adding a note explaining the wide variance based on indicator complexity.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Replace version placeholder with actual release version.

Line 9 contains "v3.0.0-preview.XXX" which appears to be a placeholder. Replace with the actual preview version number (e.g., "v3.0.0-preview.1") to match the current release.

🤖 Prompt for AI Agents

In docs/pages/performance.md around line 9, the version string
"v3.0.0-preview.XXX" is a placeholder; replace it with the actual preview
release tag (for example "v3.0.0-preview.1") so the page reflects the current
release version consistently; update only the placeholder text on that line and
verify the page title and any related version references match the real release
number.