Node.js Technical Steering Committee (TSC) Meeting 2022-12-14

[mhdawson]

Time

UTC Wed 14-Dec-2022 16:00 (04:00 PM):

Timezone	Date/Time
US / Pacific	Wed 14-Dec-2022 08:00 (08:00 AM)
US / Mountain	Wed 14-Dec-2022 09:00 (09:00 AM)
US / Central	Wed 14-Dec-2022 10:00 (10:00 AM)
US / Eastern	Wed 14-Dec-2022 11:00 (11:00 AM)
EU / Western	Wed 14-Dec-2022 16:00 (04:00 PM)
EU / Central	Wed 14-Dec-2022 17:00 (05:00 PM)
EU / Eastern	Wed 14-Dec-2022 18:00 (06:00 PM)
Moscow	Wed 14-Dec-2022 19:00 (07:00 PM)
Chennai	Wed 14-Dec-2022 21:30 (09:30 PM)
Hangzhou	Thu 15-Dec-2022 00:00 (12:00 AM)
Tokyo	Thu 15-Dec-2022 01:00 (01:00 AM)
Sydney	Thu 15-Dec-2022 03:00 (03:00 AM)

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Technical%20Steering%20Committee%20(TSC)+Meeting+2022-12-14&iso=20221214T1600
• or https://www.wolframalpha.com/input/?i=04PM+UTC%2C+Dec+14%2C+2022+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1FU7NRjy6c-y3VP4w7mFEAYdZTZ5eJwULqv-mXuT5Hzg/edit

Agenda

Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/node

• doc: change fetch from experimental to stable #45684
• Expose Undici's ProxyAgent and setGlobalDispatcher within Node #43187

Invited

• Antoine du Hamel @aduh95 (TSC)
• Anatoli Papirovski @apapirovski (TSC)
• Beth Griggs @BethGriggs (TSC)
• Ruben Bridgewater @BridgeAR (TSC)
• Сковорода Никита Андреевич @ChALkeR (TSC)
• Colin Ihrig @cjihrig (TSC)
• Danielle Adams @danielleadams (TSC)
• Franziska Hinkelmann @fhinkel (TSC)
• Geoffrey Booth @GeoffreyBooth (TSC)
• Gireesh Punathil @gireeshpunathil (TSC)
• James Snell @jasnell (TSC)
• Joyee Cheung @joyeecheung (TSC)
• Chengzhong Wu @legendecas (TSC)
• Matteo Collina @mcollina (TSC)
• Michael Dawson @mhdawson (TSC)
• Rafael Gonzaga @RafaelGSS (TSC)
• Darshan Sen @RaisinTen (TSC)
• Richard Lau @richardlau (TSC)
• Robert Nagy @ronag (TSC)
• Michaël Zasso @targos (TSC)
• Tobias Nießen @tniessen (TSC)
• Rich Trott @Trott (TSC)

Observers/Guests

Notes

The agenda comes from issues labelled with tsc-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

Zoom link: https://zoom.us/j/611357642
Regular password

Public participation

We stream our conference call straight to YouTube so anyone can listen to it live, it should start playing at https://www.youtube.com/c/nodejs+foundation/live when we turn it on. There's usually a short cat-herding time at the start of the meeting and then occasionally we have some quick private business to attend to before we can start recording & streaming. So be patient and it should show up.

---

Invitees

Please use the following emoji reactions in this post to indicate your
availability.

• 👍 - Attending
• 👎 - Not attending
• 😕 - Not sure yet

[mhdawson]

Sorry this is late to be opened.

[targos]

There are only two issues on the agenda and we discussed them last week.

[Trott]

I'll be there long enough to at least decide we don't need to have the meeting. 😀

[tniessen]

I'll be there but slightly late.

[joyeecheung]

I'll be late or cannot attend, as an update for startup performance:

• There had been a gradual regression of startup performance starting from v15. v19 is about 40%+ slower than v14
• bootstrap: lazy load non-essential modules node#45659 improved baseline startup by 17-18%
• build: disable v8 snapshot compression node#45716 improved baseline startup again by 17-18%, reversing the regression, with a 2.9% increase in binary size.
• bootstrap: optimize modules loaded in the built-in snapshot node#45849 will improve baseline startup again by 10-11%, resulting in a overall 14-15% improvement compared to v14. Startup involving loading of all common builtin modules would still be 4-5% slower, because we simply have more internal modules and subnamespaces now.
• I am playing with compression of snapshot/source code/code cache in the binary. Zlib isn't a good choice at this point (as the regression fixed in build: disable v8 snapshot compression node#45716 demontrated. V8 turned off the compression on desktop by default for the same reason). lz4 and/or zstd might be better. As reference LLVM uses zstd and Deno uses a combination of both. This would be an internal util. I am leaning towards lz4 because of faster decompression & it's tiny & it's already in chromium so it might be used somewhere else in V8 in the future.

[GeoffreyBooth]

@joyeecheung Can we write down somewhere, perhaps in https://github.com/nodejs/node/tree/main/doc/contributing, how to avoid these regressions in the future? Like a guide to how to make modules snapshottable, how to add them to the snapshot, how and when to lazy-load things, how and when to avoid circular dependencies, etc. cc @nodejs/performance

[tniessen]

Did I miss the meeting?

[RaisinTen]

The meeting just ended

[joyeecheung]

how to make modules snapshottable, how to add them to the snapshot, how and when to lazy-load things

See the comments in https://github.com/nodejs/node/blob/main/lib/internal/bootstrap/node.js - I suspect this place is much more noticeable than any doc we have in the repo (I read an old version of it before I started to do any work in startup, and it was also mention in blogs/books). The file itself is one of the oldest in the code base (if we disregard the exact directory where it is).

how and when to avoid circular dependencies

That probably should go to lib/README.md (which does not yet exist).

[mhdawson]

PR for minutes - #1320

[BridgeAR]

@GeoffreyBooth

how and when to lazy-load things

We have a test that indicates when new modules are added to the startup. I originally wrote it when starting to lazy load modules to improve the startup time before.

Shall we have a stronger indicator to prevent this in the future?

[joyeecheung]

We have a test that indicates when new modules are added to the startup

I think the issue is that we have the list but we still didn't care much when it was extended. Also the test does not show how the modules were actually loaded (e.g. from snapshot, or being compiled at runtime, the latter is much more expensive even with the help of code cache, the former is cheaper, but not free).

[joyeecheung]

I think another cause was that since we stopped tracking the performance of main/releases in general, we stopped noticing about regressions like this (to catch nodejs/node#45716 in time we needed to run the benchmarks after every V8 update, to catch nodejs/node#45659 and nodejs/node#45849 in time we needed constant monitoring of the performance because it happened gradually, one module would not significantly slow down the startup but when we gradually doubled the number of internal modules, the impact would be significant).

[GeoffreyBooth]

See the comments in nodejs/node@main/lib/internal/bootstrap/node.js

I’ve never heard about this file until now, and I’ve been working in this codebase for something like five years now. We could at least link to this file from the contributor guide.

[joyeecheung]

I’ve never heard about this file until now, and I’ve been working in this codebase for something like five years now.

You've been missing all the fun ;) The comments even start with Hello, and welcome to hacking node.js! (which is 12 years-old)

We could at least link to this file from the contributor guide.

Do you want to write a guide on hacking lib/ in general, or are you asking me to?

[GeoffreyBooth]

Do you want to write a guide on hacking lib/ in general, or are you asking me to?

I don’t have the time or knowledge to write a guide on hacking lib in general, but if you or someone else does I think that would be very valuable.

I’m happy to open the PR to the contributor guide to just add a link to this file, unless someone else wants to beat me to it. I’m not sure when I’ll be able to get to it.