src: use constexpr table for GetOctalCode

[ansh1406]

Replaced the runtime std::vector<std::string> cache used by GetOctalCode() with a compile-time constexpr lookup table of std::string_view.

Changes

1. GetOctalCode() now returns std::string_view instead of const std::string&.

2. There are two call sites that use GetOctalCode():

   • src/node_snapshotable.cc: The returned value is streamed directly to an std::ostream, so no changes were required.
   • tools/js2c.cc: Updated the implementation to use std::string_view::data() instead of std::string::c_str().

Verification

• Verified that the generated output is identical for all 256 byte values.
• Full build completed successfully on Debian 13.4 (x86_64, GCC, make).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.24%. Comparing base (b4c7be3) to head (9e25225).
⚠️ Report is 44 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #64471      +/-   ##
==========================================
+ Coverage   90.23%   90.24%   +0.01%     
==========================================
  Files         741      741              
  Lines      241604   241593      -11     
  Branches    45520    45520              
==========================================
+ Hits       218010   218027      +17     
+ Misses      15120    15113       -7     
+ Partials     8474     8453      -21     

Files with missing lines	Coverage Δ
src/embedded_data.cc	100.00% <100.00%> (+10.52%)	⬆️

... and 35 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ansh1406]

lint-js-and-md check got timed out for some reason. My changes are out of it's scope. Can a maintainer please re run it if it's necessary.

[avivkeller]

cc @nodejs/performance

[joyeecheung]

What is the value proposition of this? The utility is only used at build time, if we change that to a constexpr table we are trading perhaps a few nanoseconds of speedup at build time for an increased binary size, I am not sure that's really something we want..(in general we are willing to spend more build time even to decrease binary size).

[ansh1406]

What is the value proposition of this? The utility is only used at build time, if we change that to a constexpr table we are trading perhaps a few nanoseconds of speedup at build time for an increased binary size, I am not sure that's really something we want..(in general we are willing to spend more build time even to decrease binary size).

@joyeecheung Oh, I wasn't aware of that preference. If that's the case, the previous implementation is probably the better choice. I also noticed that it uses std::vector and std::string even though both the array size and string lengths are known beforehand. Let me know if you'd prefer that I close this PR and open a new one addressing only those parts, or if changes of that nature aren't considered worthwhile either.

[joyeecheung]

I think using std::string_view etc. is fine if it doesn't add complexity in the lifetime management. At the end of the day it's probably only making a difference of a few milliseconds/nanoseconds during the build process but does not affect the runtime, so I'd prioritize simplicity over performance