René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Investigating a Severe Performance Regression in Node.js v22 and v24","articleBody":"# Investigating a Severe Performance Regression in Node.js v22 and v24\n\nHello everyone,\n\nWe (@forwardemail) have been running some benchmarks with `better-sqlite3-multiple-ciphers` and came across what appears to be a significant performance regression in newer Node.js versions. I wanted to share my findings in case they are helpful to the community, especially for those who rely on native modules with SQLite.  We use encrypted SQLite databases for storing folks email, see our write-up at \u003chttps://forwardemail.net/en/blog/docs/best-quantum-safe-encrypted-email-service\u003e.\n\n## Summary of Findings\n\nMy benchmarks indicate that Node.js v24 is approximately **57% slower** than v20 for SQLite SELECT operations, while Node.js v22 shows a smaller regression of about 7-9%. These findings suggest the performance issue may not be specific to `better-sqlite3` but could be related to a broader change in the V8 engine that affects native modules.\n\n## Benchmark Results\n\nI've created a benchmark suite to reproduce these results, which you can find here: https://github.com/forwardemail/sqlite-benchmarks\n\nHere is a summary of the results I observed with `better-sqlite3-multiple-ciphers`:\n\n| Node.js Version | SELECT ops/sec | vs v20 LTS |\n|---|---|---|\n| v20.19.5 (LTS)  | 18,383         | baseline   |\n| v22.21.1        | ~17,000        | -7%        |\n| v24.11.1        | ~7,900         | **-57%**   |\n\nAs the table shows, the performance on v24 is less than half of that on v20 for this specific database workload.\n\n## Potential Root Cause\n\nAfter some investigation, I believe this regression may be linked to the **V8 13.6 engine upgrade** in Node.js v24. The V8 versions for each Node.js release are as follows:\n\n*   **Node.js v20**: V8 11.3 (Stable Performance)\n*   **Node.js v22**: V8 12.4 (Minor Regression)\n*   **Node.js v24**: V8 13.6 (Major Regression)\n\nThe most significant change in V8 13.6 appears to be the move to a **V8-owned CppHeap** ([nodejs/node#52718](https://github.com/nodejs/node/issues/52718)), which alters how C++ objects are managed and garbage collected in native modules. While this change was intended to simplify the API, it seems to have had an unintended impact on the performance of native modules that frequently cross the JS/C++ boundary.\n\n### How This Might Affect SQLite Performance\n\nThe performance-critical paths in `better-sqlite3` involve frequent C++ object allocation, heavy interaction between JS and C++, and string conversions. The new V8-owned CppHeap may have introduced different garbage collection timing, allocation patterns, or boundary-crossing overhead that could be contributing to this slowdown.\n\n## Related Upstream Issues\n\nThis issue may be part of a broader pattern of performance regressions in recent Node.js versions:\n\n1.  **Startup regression**: [nodejs/performance#180](https://github.com/nodejs/performance/issues/180)\n2.  **Module loading regression**: [nodejs/node#60397](https://github.com/nodejs/node/issues/60397)\n3.  **CppHeap deprecation**: [nodejs/node#52718](https://github.com/nodejs/node/issues/52718)\n\nThese issues suggest that V8 11.3 (in Node.js v20) may have been a more optimized version for native module performance.\n\n## Suggestions for a Path Forward\n\nI've put together some thoughts on how we might be able to approach this. I'm happy to help with any of these steps.\n\n### For Users Experiencing This Issue\n\nFor those affected by this performance regression, a possible short-term workaround could be to remain on **Node.js v20 LTS**. It appears to be the most stable and performant version for this workload and is supported until April 2026.\n\n### Potential Areas for Investigation\n\nIt seems the performance degradation might be linked to the CppHeap changes in V8. It could be beneficial for the V8 and Node.js teams to investigate this further. Some areas that might be worth exploring include:\n\n*   **Benchmarking the CppHeap regression**: A performance comparison of native modules before and after the CppHeap changes could help confirm the impact.\n*   **Profiling hot paths**: It might be useful to profile the following areas:\n    *   Object allocation in the V8-owned CppHeap\n    *   Garbage collection behavior for frequently created C++ objects\n    *   Overhead from JS/C++ boundary crossings\n    *   String encoding/decoding with `WriteUtf8V2()`\n\n### Possible Long-Term Solutions\n\nIf the regression in V8 cannot be addressed upstream, it might be necessary for native modules like `better-sqlite3` to adapt. Some potential strategies could include:\n\n*   **Object pooling**: Reusing statement objects to reduce allocation overhead.\n*   **Batch operations**: Processing multiple rows at once to minimize boundary crossings.\n*   **Optimized string handling**: Caching string conversions or exploring alternative V8 APIs.\n*   **Manual memory management**: Taking more explicit control over the object lifecycle to mitigate GC issues.\n\nHowever, it seems that addressing this at the V8 level would be the most effective solution, as it would benefit all native modules.\n\n## Reproduction\n\nTo reproduce the benchmark results, you can clone the repository and run the tests:\n\n```bash\ngit clone https://github.com/forwardemail/sqlite-benchmarks.git\ncd sqlite-benchmarks\nnpm install\n\n# Test with different Node.js versions\nnvm use 20 \u0026\u0026 npm run benchmark\nnvm use 22 \u0026\u0026 npm run benchmark\nnvm use 24 \u0026\u0026 npm run benchmark\n```\n\nThe results have been consistent on both macOS ARM and Linux x64.\n\n## Questions for the Community\n\n1.  Has anyone else encountered similar performance issues with v24?\n2.  Are there any V8 flags or Node.js options that might help mitigate this?\n3.  Would it be appropriate to escalate this to the V8 team for their input?\n\nI am more than willing to assist with further profiling, testing, or providing any additional information that might be helpful. Thank you for your time and consideration.\n","author":{"url":"https://github.com/titanism","@type":"Person","name":"titanism"},"datePublished":"2025-11-14T18:54:18.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":14},"url":"https://github.com/60719/node/issues/60719"}