I've researched this in order to determine just how much impact, if any, this change would have on delivered performance. Based on the data I collected, it's highly unlikely that this has any noticeable impact unless I've overlooked something important.  I ran three main tests:

1. Started up our "CNAPI" server, an node HTTP client and server that's part of our stack.  This is normally a daemon.  I measured how many times `get_builtin_module()` is called during startup and how much total time is spent in it, since we would expect that it does not normally get called during steady-state operation.  The result:

<pre>
[root@32e28a8b-b72f-469d-b48e-3a14fb59a066 (emy-eng:cnapi0) /opt/smartdc/cnapi]# dtrace -n 'pid$target::_ZN4node18get_builtin_moduleEPKc:entry { @ = count(); self->start = timestamp; }' -n 'pid$target::_ZN4node18get_builtin_moduleEPKc:return/self->start/ { @time = sum(timestamp - self->start); self->start = 0; }' -c "/opt/smartdc/cnapi/build/node/bin/node /opt/smartdc/cnapi/bin/cnapi.js"
...
               17
           179906
</pre>

So it's called 17 times, and we record a total of about 180 microseconds consumed by these calls.  But, there's a catch: that number is so small that a lot of it is likely probe effect.  So I also created a null function and probed that:

<pre>
root at 75a6ca12-faf8-ed56-bfd3-b89c5020c47c in /var/tmp
# cat null.s
.globl null
.type null, function
null:
        pushl %ebp
        movl %esp, %ebp
        leave
        ret
.size null, . - null
root at 75a6ca12-faf8-ed56-bfd3-b89c5020c47c in /var/tmp
# !gcc
gcc -o null null.c null.s
root at 75a6ca12-faf8-ed56-bfd3-b89c5020c47c in /var/tmp
# !dtrace
dtrace -n 'pid$target::null:entry { @ = count(); self->start = timestamp; }' -n 'pid$target::null:return/self->start/ { @time = sum(timestamp - self->start); self->start = 0; }' -c ./null
dtrace: description 'pid$target::null:entry ' matched 1 probe
dtrace: description 'pid$target::null:return' matched 1 probe
dtrace: pid 68245 has exited

               17
            40998
</pre>

So we might conclude that at least 41 of the 180 microseconds is probe effect... but the exact amount depends on cache misses, and this is pretty much the best possible case: we invoke no other code in between null function calls.  The first call in this case has quite a bit more probe effect:

<pre>
root at 75a6ca12-faf8-ed56-bfd3-b89c5020c47c in /var/tmp
# cat null.c
extern void null(void);

int
main(void)
{
        int i;

        for (i = 0; i &lt; 1; i++)
                null();

        return (0);
}
root at 75a6ca12-faf8-ed56-bfd3-b89c5020c47c in /var/tmp
# !gcc
gcc -o null null.c null.s
root at 75a6ca12-faf8-ed56-bfd3-b89c5020c47c in /var/tmp
# !dtrace
dtrace -n 'pid$target::null:entry { @ = count(); self->start = timestamp; }' -n 'pid$target::null:return/self->start/ { @time = sum(timestamp - self->start); self->start = 0; }' -c ./null
dtrace: description 'pid$target::null:entry ' matched 1 probe
dtrace: description 'pid$target::null:return' matched 1 probe
dtrace: pid 68336 has exited

                1
            12260
</pre>

If every probe firing were as expensive as this one, probe effect would account for 100% of the observed time.  The true probe effect is likely somewhere in between, likely closer to the higher figure since calls to `get_builtin_module()` tend to be separated by a fair amount of internal work.  We might therefore conclude that, in today's code, the cost of this function is probably in the low single digits (microseconds).

2. I repeated this measurement on the same server running normally.  Over a period of 5 minutes, no calls to `get_builtin_module()` were observed.  This is not surprising; since the return is cached, this function is called only on the first use of each builtin module.

3. Then, to rule out the possibility that this function is called in the path of servicing requests, I enabled the same probes and ran 100 HTTP requests, each of which does a fair bit of work.  Once again, no called to `get_builtin_module()` resulted.

We could certainly do this with other test programs (it might be more helpful to do so using something publicly available that everyone agrees is a useful test case), but this basically confirms what we would expect: this function is rarely called, is not called as part of normal, steady-state operation, and takes at most a few microseconds to complete: certainly less than 7 microseconds, probably only 1 or 2.  Currently in this version of node, there are 18 builtin modules (we apparently don't use all of them).  If someone were to create a node process in which 100 binary add-on modules were loaded before all of the built-ins were used for the first time, this function would take about 5 times longer to complete -- perhaps as much as 25 microseconds each time, or less than 500 microseconds over the lifetime of the node process.  This does not seem significant, even in such an extreme and unlikely case, especially since the extra cost occurs only at startup.

Perhaps there are other use cases not captured in my test, where this function would be called far more frequently.  In order to test this, I captured the above trace data across all of our services, one an SDC headnode with 46 node processes and the other a Manta node with 131 node processes, for 5 minutes.  If there is such a use case, none of our wide range of services exemplified it during my observation window; there were once again no calls to `get_builtin_module()`.  Did you have a particular use case or piece of test code in mind?

I'm willing to make this change; it seems mostly harmless at least in the short term.  But given the above it doesn't seem to have any meaningful benefits, either.  With all that in mind, do you still want the change?