Node.js Performance WG Session  ## Metadata - Author: [[OpenJS Foundation]] - Full Title: Node.js Performance WG Session - Category: #articles - Document Note: --- tags: [#nodejs, #performance, #opensource] - #nodejs - #performance - #opensource Author: Node.js Performance Team Source: Node.js Performance WG Session (YouTube) Reference: [Node.js Performance WG Session](https://www.youtube.com/watch?v=D7gd2pLo_QY) date created: 2025-08-24 01:00 --- # Title: Node.js Performance WG Session — Strategic Updates and Optimizations ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary: The Node.js Performance Team, formed in late 2022, has rapidly advanced as a **strategic initiative**. Over 30 performance contributions have improved core functionalities, notably text encoding/decoding, URL parsing with the Ada library, and startup performance. Significant gains (150%+ boosts in event creation, SIMD-powered URL parsing 400–500% faster than prior versions) illustrate the impact of **C++ optimizations, V8 Fast API use, and hardware acceleration**. Future goals include reducing JavaScript/C++ communication costs, streamlining streams and fetch with native code, and strengthening **benchmarking infrastructure** for consistent performance testing. --- ## 📖 Main Content: The session highlights **how strategic prioritization of performance in Node.js** has enabled breakthrough optimizations, while also confronting governance and technical limits. Key themes: - **Governance shift**: Performance designated a strategic initiative instead of a working group. - **Major wins**: Ada URL parser, UTF-8 fast path, V8 Fast API usage, private property refactors. - **Challenges**: Balancing C++ vs. JavaScript implementations, fragile benchmarking infra, JIT unpredictability. - **Next goals**: Reduce cross-language overhead, expand SIMD/vectorization optimizations, re-implement streams/fetch in C++ for efficiency. ### 🗒️ Notes - [0:03](https://www.youtube.com/watch?v=D7gd2pLo_QY&t=3) — Performance team overview, founded Nov 2022, now a strategic initiative. - [0:55](https://www.youtube.com/watch?v=D7gd2pLo_QY&t=55) — 30 contributions tagged “performance” since Oct 2022. - [2:43](https://www.youtube.com/watch?v=D7gd2pLo_QY&t=163) — Ada URL parser → 400–500% faster than Node 16, Node 20 fastest JS runtime for URLs. - [5:31](https://www.youtube.com/watch?v=D7gd2pLo_QY&t=331) — Private properties improve URL compliance + 20% performance gain. - [8:15](https://www.youtube.com/watch?v=D7gd2pLo_QY&t=495) — Future goals: reduce JS/C++ calls, leverage V8 Fast API. - [11:02](https://www.youtube.com/watch?v=D7gd2pLo_QY&t=662) — Plan: move streams & fetch into C++ for efficiency. - [16:28](https://www.youtube.com/watch?v=D7gd2pLo_QY&t=988) — Ada outperforms curl & Servo with SIMD-based optimizations. - [20:58](https://www.youtube.com/watch?v=D7gd2pLo_QY&t=1258) — Hardware acceleration & runtime comparisons; V8 excels at scale. - [23:29](https://www.youtube.com/watch?v=D7gd2pLo_QY&t=1409) — CI fragility; need for stable benchmarking infra. - [25:47](https://www.youtube.com/watch?v=D7gd2pLo_QY&t=1547) — Upcoming I/O ring → 8x faster file ops. --- ## 📖 References: - Node.js Docs: [Performance Hooks](https://nodejs.org/api/perf_hooks.html) - V8 Fast API Documentation - GitHub: [Ada URL Parser](https://github.com/ada-url/ada) --- ## 🗣️ Paraphrase: 1. **Original**: “Performance became a strategic initiative as a result of governance recommendations.” **Paraphrase**: Governance rules prevented Performance from becoming a working group, so it was elevated to a strategic initiative. 2. **Original**: “Ada makes Node 20 the fastest runtime for URL parsing, 400–500% faster than Node 16.” **Paraphrase**: By introducing Ada, Node.js 20 surpasses all runtimes in URL parsing, achieving up to five times the speed of earlier versions. --- ## 📰 Newsletter: ⚡ **Node.js Performance Gains Speed Ahead!** The Node.js Performance Team is on fire 🔥. Since late 2022, they’ve delivered huge wins: - **Ada URL parser** → 400–500% faster. - **UTF-8 fast paths** → major gains in text encoding/decoding. - **Event handling** → 150% faster. - **Upcoming I/O ring** → file ops up to 8x faster. Next up: reducing JS ↔ C++ communication overhead, streamlining fetch/streams, and pushing SIMD/vectorization further. If you’re into speed (and who isn’t?), keep an eye on Node.js 20+ for the fastest runtime improvements yet. 🚀 👉 Join the discussions: [Node.js Performance Team](https://github.com/nodejs/performance) --- ## ✅ Action Items: - Position this session as a **case study** in OSS governance: strategic initiatives vs. working groups. - Connect Node.js performance strategies to **WordPress ecosystem optimizations** (e.g., PHP performance teams). - Apply **benchmarking lessons** to FAIR/WPCC: sponsor infrastructure for sustainable testing. - Highlight cross-project standardization (e.g., SIMD, native code libraries) in OSPO advocacy work. --- ## 🧪 Hypotheses: - SIMD/vectorization optimizations produce sustainable, cross-runtime improvements. - C++ re-implementation of streams/fetch reduces bottlenecks by 30%+. - Stable benchmarking infra is necessary for long-term reproducibility in OSS. ### 📊 Methodology: - Benchmark Node.js versions on identical hardware (bare metal, isolated). - Compare performance across workloads: small vs. large datasets. - Cross-project collaboration with V8, WebKit, Servo for portability. ### ❓ Questions: - Should Node.js streams be fully re-implemented in C++? - How can OSS fund stable benchmarking infra across ecosystems? - What governance structures best support performance as a priority? ### 🔮 Future Research: - Explore SIMD adoption beyond URLs (e.g., fetch, streams). - Investigate standardized benchmarking frameworks across runtimes. - Study governance models (strategic initiatives vs. WGs) in OSS. ### 💡 Implications: - OSS projects benefit from **shared optimization efforts**. - Performance as a strategic initiative creates **cross-ecosystem models**. - Sustained infra investment may define future OSS scalability. --- ## 🧠 Learning Styles Assessment: - **Visual**: Limited diagrams; could use perf charts. - **Aural**: Live presentation supports auditory learners. - **Verbal**: Explanations clear; analogies sparse. - **Kinesthetic**: No hands-on demos; could include benchmarking tasks. - **Logical**: Strong reasoning with metrics. - **Social**: Q&A provides collaborative element. - **Solitary**: Few reflection prompts. - **Naturalistic**: None; could analogize optimization to ecological balance. --- ## 📊 Accessibility Assessment: - ✅ Transcript provided. - ❌ No visual aids or alt-text. - ❌ CI infra fragility undermines inclusive access to reproducible benchmarks. - Recommend charts + clear labeling for perf improvements. --- ## 🌍 DEIB Assessment: - Language inclusive, neutral. - ❌ Limited cultural/global perspectives. - Add multilingual captions + regional case studies. - Psychological safety: Encouraged open Q&A → positive. --- ## ✅ Logical Validity: - **Strong reasoning**: C++ vs. JS tradeoff analysis clear. - **Valid causal chain**: SIMD → faster URL parsing. - **Balanced**: Acknowledges JavaScript/JIT limitations. - No fallacies detected. - Tone: **Technical, collaborative, transparent**. --- ## 🔍 DARVO Analysis: - **Deny**: None. - **Attack**: None. - **Reverse Victim**: None. 👉 Content constructive; no DARVO tactics present. - Summary: The Node.js Performance WG session discussed the team's recent work and plans for the future. The performance team is not a working group but is centered around understanding the business domain and organizational environment, and its objective is to stress test and improve the client's ongoing thinking about their evolving challenges. The internet has made it easier for consultants to acquire the necessary knowledge to become effective sparring partners. However, the role demands a particular temperament, personality, and preparedness in terms of industry knowledge, which cannot be taught overnight. - URL: https://www.youtube.com/watch?v=D7gd2pLo_QY&list=PLyspMSh4XhLO15jJD9Sj069fN18j12AbQ&index=8&ab_channel=OpenJSFoundation today I'm going to talk about node.jsperformance teamit's a it's not a working group but uh ateam so let me correct that before Istart so I'm going to give some smallsummary what we did in the past sixeight months and then what we plan to doand you will get the idea and if you ifyou have any questions if you have anyideas about what's important what kindof performance issues you have you can askand we can continue doing it so we foundit node.js performance team aroundNovember 2022 it's quite new we havemore than 20 members weum just recently about a month agoperformance became a strategicinitiative as a result of me proposingthat performance team should be aworking groupbut due to the governance of node.js and how working groups needs to have thisparticular role in like like a dailydaily routine in order to be a workinggroup and performance isn'tum TSC members recommended theperformance to be a strategic initiativeas a result I became the championum on top of that we have biologymeetings we we have been doing it forthe past five five five six months wehave around six sevenum on average attendees to each of these meetings and I think we're doing somereally great work and if you are ifyou're interested and enjoying and andlike in contributing to node.js you arealways welcome and I will be more thanhappy to help you with any kind ofissues that you faceso let me give you some statistics wehave 30 different contributions underthe tag of performance uh since October22 most of them areDecember miners some of them are example Majors which means that these arebreaking changes and most of them arenotable changes due to the nature ofthem because they're they're making lotsoflots of impactso some significant changesthat we did wasum Justin no 20and also in nor 18 text encoder and textdecoders was improved by a significant margin that's that's because we added afast path for utf-8 this means that wedon't need to go to ICU which is theencoding Library behind node.js and it'squite fast this means that in the uh inthe next couple of months we will seesome really great webassemblyapplications that benefit from thisperformance Improvement becausewebassembly uses text decoder and textencoder to communicate between the webassembly side and the node.jssite Force strings on top of that one ofthe major issue major improvements wasURL and URL such search prompts wedeveloped a library called Ada and it isright now400 or 500 percent faster than node 16so not 20 became the fastest one in allJavaScript runtimes in terms of parsingURL this means that our the current infrastructure of node.js allows us toachieve such certain significantperformance improvements and this becamethe example that in the future certainparts of node.jsr extremesFetch and any other small subsystems canbenefit from it on top of that becauseof we going back to URL and like usingour own implementation Ada we don't need toum our right now ICU free builds whichwhich means that node.js films thatdoesn't require any native ICU canproperly parse URL right now because wedon't need it anymoreon top of that there has beensignificant work around improving thesestartup performersum I think Joey was one of the bigpersons that people who significantlyinvested a lot of time on improving it and we are seeing 20 30 and I thinkRafael when he releases the performancedocument you will see thethe exact numeric values on top of thatthere's there's been some improvementson the event creation event temperatureand those kinds of things there are acouple of people still working on how toimprove event temperatures and forAdvent listener and remove event listeners and it's an ongoing processbut even with event is trusted we haveseen 150 percent improvement over thecreation of an event this was adiversion from the standards for by asignal like by a small portion but thatparticular change resulted in a reallygreat performance boost on top of thatwe have a reallyumthe ashis to my system refactoring the existing classes to useprivate properties and remove brandingwhich means that whenever if you pass aclass other thanURL to a URL function it needs to throwan error according to comply with thespecification and in order to do thatJoey a couple of months ago recommendedusing private properties ofJavaScriptto validate that Brands but previously it was somewhere major change becausethe error message behind that waschanged but not 20 and note 21 is goingto accept those changes and it's goingto improve the performance of each ofthose operations but by at least 20percent I assumeum this is because it was done with theV8 V8 private properties handles TheBranding inside them and if you rely onthem then we don't need to check in so and so forthon top of thatum right now in no details there is afunction called to USB string and whichno we create 11.2 I think 11.3 I'm notquite sure which versionumVA team implemented string Prototype 2well-formed which is uh exact replica ofthe two USB string functionality andthis includes more than 200 performanceboost this means that any live any function that uses it including uhany function that has a specificationbehind it like url url so search promptor web streams that any function thatpasses string is going to have asignificant performance boost becausefor every time that we have to call toESP screen we were calling C plus plusand the communicationduration between string and the C plusplus is always a problem on top of that because of the changesthat we did with URL and your searchprompts on and also some smalloptimizations we saw around eight to tenpercent module loading esm moduleloading performance boost this isbecause we select we use the specificfunction to check if a file is the fileor directory is a directory so these aresome of the significant changes that wedid in the past eight months and there are lots of great people working on thisand I'm happy to help tell you about allof those people's work right nowum but yeah solet me continue to our goals so this isgoing to be my lastumslide after thatum I I want to communicate and talk withyou whenever however I can with this um internet problem but yeah so the goal isum as well as the Strategic initiativeperforms but performance became astrategic initiative and in order tomake the most impact uh there are fourthings that I am planning to work and Iam sure that other people are interestedin working on these two one of them isreducing C plus plus JavaScriptcommunication uh it's actually most mostof the functions in node.js um in the JavaScript site called C plusplus functions more than one timesinstead of connecting to the C plus plusside and making those the executions uhby bulksoum by reducing that you will we will seemore than 20 30 boost by just changingcouple of lines and if we do it in allof the projects we will see some greatprojects they're great impacts uh the second item is V8 Fest APIum just around for four or five monthsagoumwe wrote a documentation for how to addV8 Fest API uh to an existing C plusfunction in node.js and upon afterwriting it there has been four or fivedifferent uh optimizations done innode.js course and it has seen somereally great impacts even though V8 fast API has a lot of limitationswhile looking into this issue andand keep that and keeping an eye on it Ithink that there are lots of otherplaces and we can that we can leverageit as well the third item is streamsthat we are seeing a lot of performanceissue a lot of different JavaScriptruntimes small try to solve this problem from a different perspective such asnever leaving the C plus plus or buyingum orumby not piping the C plus plus datainstead of passing through theJavaScript and implementing those kindsof things it's possible tomake this kind of uh Improvement as wellbut this requires a really excessivework which means that implementingsome portions of the streams in C plus plusumthen you Lemire and I uh our planplanning to work on streams andafterwards fetch in the next year so buteven before that I think that's thereare lots of things that we can do thatwill benefit both Fetch and otherapplications that uses itum the last item is fetch I put it inthe last part because right now we have we have seen some really uh performancerelated issues because of the JavaScriptimplementation the just theimplementation is correct it's efficientbut due to the nature of the JavaScriptlanguage and also how hard it is TheBenchmark because of the flakiness ofthe jit compilers they are having someissues and in order to solve the problemof patch performance we need to solve the problem of streams and there areother sub uh problems that also willbenefit if we improve streams as well sothat's what I have in my mindum I I I think that's rewriting thefetch in C plus plus would be asignificant Improvement but this ismostly me speaking out of the bluewithout reading the specification andthere are lots of people um in the undishi team that can help usbenefit those kinds of things but yeahsothat's it from my site and if you haveany questions or any uh anything thatyou want to share I'll be happy toanswer that do we have any questionsomeone yes can you can you hear meokay I guess notthank you thank you for the presentationyeah I don't know if someone got somespecific question about performance ornextwalk even if you already presented thator some IDin which some people want to be involved on how we can make node.js fasterwe we got one uh yeah we'll be easier ifyou come hereI can't see youbut yeah it's okay all right uh it's uhI was just wanted to find out if there'sany efforts around when you're a lot of it sounds like Cplus plus code that you're puttingtogether for streams and things likethat if there'sparticular uh I guess the first step isunderstanding where the performanceissues are and then from therefiguring out which parts need to bebrought into native codeI guess if they're a way to share someof thatkind of information about whatlike for example with streams what partsof streams would one benefit the most from uh making into native code and getget the highest benefits so obviously ahuge surface area thereand and are there more kind of thingslike with Euro whether it's that URLeffort to to make a native URL uh parserthat can then benefit like lots ofplatforms and lots of environments Ithink is there a way to figure out Arethere specific you know aspects of thesethings that that can be optimized withsort ofportable native interfaces that that can benefit you know other projects orthought of as cross-collaborations youknow winter CG level collaborations andjust things like that like I think a lotof things that stick out here is thatlike a lot of the efforts that are kindof standardization if it's acrossproject efforts uh that have come intoV8 become these performance like withthe string stuff uh if they're scoped tokind of share the the metrics and theum the the primary native targets or orif if they can be made portable if there's any aspects of that that arehorrible I guess that's the question andand discussion on that pointyeah that's that's that's a really goodquestion so the thing isumit's quite hard for me to summarize whatkind of performance issues there thereis in streams butum whatever optimizations that youprovide right now in terms of streamsand would be bounded by V8 and theoptimizations that they do so if if you optimize particularly for 11.2 forexample reduce the number of for Loopsreduce branchingum andand those kinds of small microoptimizations we would save the day butwith the next V8 version it's going tothe performance will be a lot differentso my main goal that thatum like I can share with you somenumeric values with the URL parserumright now Ada is three times faster than curl and six times faster than Servo URLwhich is the URL behind URL Parts behindFirefox and this is becauseumwe try to leverage ultra vectorizationum simd which is single instructionmultiple data architectures andalgorithmsso umthe issuewhatever optimizations that we do right now in the JavaScript site it's alwaysgoing to be bounded byumJavaScriptbig and that's the worst side of beingan old collaborator I guess because I'msaying bad things about Frameworks thatI'm I'm a collaborator on but the issueis there is a boundary and that boundaryisum either you are going to implement afunction in JavaScript site which meansthat your if you if if your if thealgorithm that you're trying to implement is complex enough it's goingto be slower with large data sets thisis the first real world scenario thesecond scenario is thatumyou implement to hold it a wholealgorithm in C plus plus site but thereis the cost of Crossing betweenJavaScript and the C plus plus site sothat's small Cost Plusum plusum implementing it on the C plus plusslides that's the that's the execution timethat's the second time and on the firsttime there is only JavaScript so formost of the solutions most of thefunctions that we have in node.js wehave two Benchmark and we have to makesure that the balance between uhcreating the solution in JavaScriptversus the balance between creating thesolution and C plus plus should notshould should be selected appropriatelybut the main issue if we cross the C plus plus side onetime the performance impactbecomes much more significant becauseright now you can use Auto vectorizationyou can you can find shortcuts you canreduce the number of memory allocationsthat you have you can keep track ofnumber of instructions that you have inthe uh in the CPU so if you track ofthem then the real engineering comes inbut in the JavaScript site whatever youdo you are going to Benchmark againstyour time and if like even with the limit limited data set of how tooptimize and particularly specificthings it's a lot harder than to do iton the C plus plus side most of the timepeople think that implementing it on a Cplus plus is a lot harder or optimizingit butbecause C plus plus and c and all thetechnology and the investment that comeswith it is there for a really long timeand it's really mature and Hardware instrumentation as well asHardware instrument counts it's quiteeasy to understand and grasp and find ashortcuts on it and the main issue isthat like I can give you a small exampleon it and one of the mostmost unperformed part of V8 right nowwhich also affects node.js is theconversion between Latin one charactersand the utf-8 of V8 string so whatwhenever whenever you send the data and node.js calls uh knowledges in theJavaScript sites calls that function inthe C plus plus side and passes a stringthis function calls it and that functiondoesn't have Auto vectorization any simdoptimizations or anything it's just afor Loop but even if you up if if youupdated function toto instead of going through an array oneby one but going through them chunk bychunk this is what simb is so you have let's say a thousand array elementsinstead of going one by one uh AVX 512allows you to go 512 and 512 anditerating through the 1000 array in twodifferent instructionsof course there are limitations butthere are lots of things that we canleverage using the hardware accelerationand why the other JavaScript runtimesare fasterum in certain benchmarks the node is that they are writing their codespecifically for Mac because most of thedevelopers that you useumhas a Mac computer and if you optimizeit particularly for it then whenever yourun npm run start or APM run Dev or npmtest it executes really fast butthis is the first initial part thesecond part was is thisum after you cross and compare I'm comparing webkit with chrome right nowV8 after you cross the initial Benchmarkand the cost of V8 optimizing itself V8becomes the faster the fastestJavaScript engine because V8 is highlyoptimized not on small things but onreally largeitems like if if youum if you parse if if you run abenchmark of 100 URLs and if youBenchmark it on webkit and V8 you will see that webkit is 40 faster but if youum Benchmark hundred thousand URLs withwith webkits and V8 then you will seethat actuallythe URL parsing on that particularruntime islike six like V8 is 60 to 80 faster thanthat so there are lots of things toconsider and what I what I'm interested in doing and is that I want to keep V8out of the uh uh out of the loop andoptimize that particular engineeringproblem and then trying to find aspecific optimization that I can reducethe cost of this serialization ofcreatine node.js I hope that answeredyour question by the wayall goodI did have a question about so you are talking about performance and improvinga lot on different topic from URL stringusing also other and everything likewe in energy s projects every timesomeone commits something that is testsbeing run against a lot of stuff do youthink also that there is some tests thatshould be added about performances or toprovide I know we add this discussionbut it could be nice also to talk about it nowdo you think improving testing strategywith performance could be great orsomething that we need to work on andthe team itself will be working on ornotsotechnically whenever someone pushessomething to node.js all benchmarks runbut they only run for once because weneed to make sure that benchmarks arevalid and there's any breaking change inthe benchmarks so um benchmarking is quite hard and quitesensitive even with node and V8 due tothe nature of widget this means that youneed to find a virtual machine or a baremetal servers and you need to run thatBenchmark on an isolated device thatthat runs that specific portion andCompares itself to the previousversion like if you're doing a nightlybuild or whatever or comparing to LTS or so right now node.jsci is one of the oneof the most fragile parts of the wholeinfrastructure and because even no GSBenchmark machine runs on Ubuntu 20 andprevious it was Ubuntu 18 which didn'teven have the gcc8 I think it was the66ers Source or something which became aproblem when I tried to introduce simpleUTF library to node.js so technicallywhat you're saying is really great and what I I think this should be thescenario but this would require aparticular machine that needs to be runat a particular interval and I don'tthink apologize right now has thatinfrastructure but if there is a companythat wants to sponsor that I will bemore than happy toprepare that whole infrastructure butagain this my my ideal solution for thistorun this particular Change Daily instead of every pull request because right noweven on a particularly specific days ittakes more than two three hours to check48 different pills right nowokay thank youdo we have another question Maybeit seems like it's all good for everyonehere thank you so much for joining us yeah oh there's one question thank youah yes you can come hereit's more like hey more like a heads upbecause we are about to release theviewb 145okay and it comes with support for Ioring for copying files and stuff likethat and we measured that it was likeeight eight eight times faster for someFS operations like right Within online on linking and things like thatso that will be probably this week we'replanning to release the beauty so we'llcreate a request on node yes afterwardsthank you so node.js is becoming fasterand faster every daythat's truegreat thank you so muchthank you so thanks again for listening and if you have any questions or any ifyou want to just talk with me I'mavailable on Twitter or GitHub I'm happyto help youand I guess also thanks again I justalso uh you can join the meeting thatare held every two Mondays I think it'son Monday yes yeah so the the nextmeeting is going to be on15 May if it's Monday so Monday 1 p.m eastern time yesperfectthank youthank you, Node.js Performance WG Session, OpenJS Foundation, 01h3j5zaba9nf6wzn98x9t5xw6.