dgram: refactor dgram to module.exports

[claudiorodriguez]

Refactor dgram module to use the more efficient
module.exports = {} pattern.

See #11611

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

Affected core subsystem(s)

dgram

[ronkorving]

What's more efficient about this? I can see the benchmark, but are you saying every time we access one of the exported properties we take a perf hit? Even if so, this is so not on any hot code path, I see little point in doing this. Even if we did change this, we would have to change all built-in modules to follow that pattern. Has anyone discussed doing that yet?

[TimothyGu]

@ronkorving, even though no mass migration has happened yet, patches like 2298bc4, 62e9609, 531de63, 804bb22, b610a4d have made it an established pattern. It is more efficient because it ensures that V8 will use "fast" properties as opposed to hashtable-based "slow" properties.

[TimothyGu]

CI: https://ci.nodejs.org/job/node-test-pull-request/6722/

[ronkorving]

@TimothyGu Thank you, I wasn't aware this was already ongoing. LGTM 👍

[joyeecheung]

@TimothyGu I think those are already fast properties without being exported this way? See #11430

[fhinkel]

Thanks! Landed in a9e64a8.

[MylesBorins]

should we backport?

[MylesBorins]

I've labelled this as don't land. I believe that these optimizations were made with turbofan in mind.

[jasnell]

-1 on backporting.