investigate: STL/heap usage reduction for ETL compatibility (#174)#177
investigate: STL/heap usage reduction for ETL compatibility (#174)#177
Conversation
Audit include/ and src/ for heap-allocating STL (vector, string, unordered_map, smart pointers, function, queue) with data-path vs setup classification, bounded-size notes, and prioritized follow-ups for optional ETL integration. Made-with: Cursor
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 3 minutes and 21 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughA comprehensive investigative documentation file analyzing STL container usage patterns and heap allocations throughout the codebase, providing an inventory-oriented methodology, categorized findings, and recommendations for potential Embedded Template Library (ETL) optimization. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/investigations/stl-etl-reduction.md`:
- Line 1: Remove the trailing whitespace that the pre-commit hook fixed in the
document titled "# Investigation: Reducing heap / STL usage for ETL
compatibility": open that file, strip any trailing spaces at the ends of lines
(or run the project's pre-commit hooks locally), save the file, and commit the
change so CI no longer fails.
- Line 30: Update the phrasing in the markdown: replace "very large" with
"arbitrarily large" or "unbounded" in the sentence that describes the on-wire
Length field, and change "consumers that" to "consumers who" when referring to
developers/organizations; the sentence also references
TpConfig::max_message_size and max_segment_size (in include/tp/tp_types.h) —
keep those symbols unchanged while applying the wording edits for improved
style.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: dfe1378f-f235-440a-afca-06498866291c
📒 Files selected for processing (1)
docs/investigations/stl-etl-reduction.md
| **SOME/IP payload sizing (for bounded designs):** | ||
|
|
||
| - The header defines **practical caps** used in validation: `DEFAULT_MAX_PAYLOAD_SIZE = 1400`, `MAX_TCP_PAYLOAD_SIZE = 65535` (`include/someip/message.h`). | ||
| - The on-wire **Length** field is **32-bit**; in principle very large logical messages are representable, but **UDP datagrams** are bounded (~**65507** bytes payload for IPv4 UDP). Larger payloads rely on **TP** segmentation; this codebase sets **`TpConfig::max_message_size` default to 1_000_000 bytes** (~1 MiB) and **`max_segment_size` ~1392** (`include/tp/tp_types.h`). |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Optional: Consider style refinements.
Static analysis flagged two minor style points:
- Line 30: "very large" could be replaced with "arbitrarily large" or "unbounded" for variety
- Line 33: "consumers that" could be "consumers who" when referring to developers/organizations
These are entirely optional readability improvements and do not affect technical content.
Also applies to: 33-33
🧰 Tools
🪛 LanguageTool
[style] ~30-~30: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.
Context: ...gth** field is 32-bit; in principle very large logical messages are representable, but...
(EN_WEAK_ADJECTIVE)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/investigations/stl-etl-reduction.md` at line 30, Update the phrasing in
the markdown: replace "very large" with "arbitrarily large" or "unbounded" in
the sentence that describes the on-wire Length field, and change "consumers
that" to "consumers who" when referring to developers/organizations; the
sentence also references TpConfig::max_message_size and max_segment_size (in
include/tp/tp_types.h) — keep those symbols unchanged while applying the wording
edits for improved style.
Made-with: Cursor
1 participant
Summary
Adds
docs/investigations/stl-etl-reduction.md: a quantitative audit of heap-allocating STL usage ininclude/andsrc/(excluding tests/examples) for #174.Key findings (high level)
std::vector<uint8_t>is central to the message / serialization / SD / TP / RPC / events data path (~202 matching lines across 37 files). Bounded ETL replacement needs an explicit max payload policy (MTU-shaped ~1400, single-buffer TCP-ish up to 64 KiB, TP default 1 MiB inTpConfig, UDP datagram cap ~64 KiB; 32-bit length field allows larger logical sizes only if the stack and product allow it).std::unordered_mapappears in 12 files; many maps are already effectively bounded (TP concurrency, session IDs, event IDs). Diagnostic enum→string maps are easy constexpr wins.std::functionis used in public callbacks and in RTOS/ThreadX/Zephyrthread_implvia heap-allocatedstd::function—the platform path is a high-value target foretl::delegateor fn-pointer context.Messagepooling on RTOS does not removevectorpayload heap on POSIX or in the object model itself.SOMEIP_USE_ETL-style) plus type aliases / capacity macros; not a required dependency for multi-platform builds.Deliverable
Full tables, file/line references, categorization (easy / moderate / hard / not recommended), suggested follow-up tickets, and optional-vs-required ETL assessment are in the report.
Made with Cursor
Summary by CodeRabbit