Performance

[arkavo-com]

Overview

While OpenTDFKit meets current functional requirements, several hot paths generate avoidable overhead. This issue captures the prioritized improvements and the acceptance criteria for completing the optimization work.

Goals

• Reduce unnecessary allocations and actor hops in NanoTDF creation/decryption flows.
• Accelerate key-generation code paths that are currently serialized despite asynchronous scaffolding.
• Minimize redundant HKDF and AES-GCM operations inside the KAS rewrap logic.
• Preserve functional parity and spec compliance while improving throughput.

Scope

1. CryptoHelper Lifetime Management

Current Pain Point

• NanoTDF.getPayloadPlaintext and createNanoTDF instantiate CryptoHelper() per call, despite the helper being stateless. Actor creation and cross-actor await introduce latency.

Acceptance Criteria

• Replace per-call instantiation with a shared helper (static instance, task-local, or converted struct).
• Remove the extra await hops from CryptoHelper convenience methods.
• Benchmarks in NanoTDFBenchmarkTests show measurable improvement (>10% reduction in per-op runtime on M1 Max reference numbers).

2. KeyStore Batch Generation Concurrency

Current Pain Point

• KeyStore.generateAndStoreKeyPairs uses withThrowingTaskGroup but each task immediately awaits self.generateKeyPair(), serializing the work.

Acceptance Criteria

• Refactor batch generation so key creation happens outside the actor (e.g., detached tasks returning raw key material before inserting into the actor).
• Maintain thread-safe insertion of results into keyPairs.
• Update benchmark tests (KeyStoreBenchmarkTests) to confirm throughput regression does not occur; document improved ops/sec if observed.

3. BinaryParser Zero-Copy Reads

Current Pain Point

• BinaryParser.read uses Data.subdata(in:), creating a copy on every header field.

Acceptance Criteria

• Switch to slicing with data[cursor..<cursor + length] or use withUnsafeBytes to avoid allocations.
• Ensure parsing logic still supports remote/embedded policy cases with key access.
• Add micro-benchmarks or instrumentation demonstrating reduced allocation count (e.g., via malloc stats or Instruments snapshots).

4. KASService Rewrap Version Hinting

Current Pain Point

• KASService.rewrapKeyInternal always derives both v12 and v13 HKDF outputs and retries AES-GCM decryption on failure.

Acceptance Criteria

• Thread NanoTDF version or binding metadata through the API so we attempt only the necessary derivation.
• Remove the exception-based fallback path in the common case.
• Existing unit tests (KASServiceTests, KASServiceBenchmarkTests) still pass; add a regression test for mixed-version interoperability if needed.

Implementation Guidance

• Start by writing or updating benchmarks to capture baseline numbers before code changes. swift test --filter "BenchmarkTests" should run cleanly.
• Optimize in small, reviewable increments; avoid combining multiple concerns in a single PR.
• Use Instruments (Time Profiler, Allocations) or Swift’s signpost APIs to validate real-world improvements when available.
• Maintain comprehensive unit test coverage. Add regression tests whenever optimizing parsing or cryptographic flows.
• Document any public API adjustments in Docs/TDF.md and update changelog entries if external behavior changes.
• Run swiftformat --swiftversion 6.2 . and swift test prior to submission. Include performance numbers in the PR description.

Completion Definition

• All acceptance criteria above are satisfied and validated by tests/benchmarks.
• Documentation reflects the changes and their rationale.
• No observed regressions in existing benchmark suites or functional tests.