Considering code for unknown Javascript engine, what considerations make some of the most impact on execution speed and memory conservation?

Question

Then, I suppose, the fuller question is, "How are those considerations affected when the Javascript engine is known (on a per popular engine basis)."

The reason I feel I need to ask "community" is because those like Strongloop who create things like Node.js, also write code like util.inherits, a function inside which, instead of: TheConstructorFunction.prototype.constructor = TheConstructorFunction they create a property definition which itself has 4 properties being set:

ctor.prototype = Object.create(superCtor.prototype, {
    constructor: {
        value: ctor,
        enumerable: false,
        writable: true,
        configurable: true
    }
});

This seems inefficient to me, but then, I've only been striving to write better Javascript for 3 years as opposed to authors of code like this. Is there an explanation for why this is or isn't efficient?

One answer says that util.inherits is not inefficient because subclass operations are rare. But considering some libraries deal with hundreds and thousands of subclass operations happening between build to test result observation, if Node.js internally uses util.inherits then that affects development time of its consumers. I think, on this level efficiency does matter and I hope util.inherits is not being used internally. I don't even understand the purpose of util.inherits. Why have it at all? I think it promotes compounding inefficiency. require('util').inherits(C1,C2); is almost synonymous and likely slower than C1.prototype=Object.create(C2.prototype); C1.prototype.constructor=C1; If it is just meant to lure consumers, I'm cool with that. My concern is if these pros are using that function internally since larger libraries will be depending on Node.js' efficiency. As for making .constructor non-enumerable... I think the case where its "enumerability" matters is rare and should be left up to the consumer, but if internal operations are depending on util.inherits, this isn't really being left up to the consumer.

Answer 1

This seems inefficient to me

No. Efficiency does not matter here. Subclassing is a rare operation, and even if the code would be slower than the simple assignment (there most likely isn't much difference) this does not affect performance.

What matters, especially for library functions like utils.inherit that are used everywhere, is correctness. So why do they use property attributes? To make the .constructor non-enumerable, like it is standard for .prototype objects that are natively created and therefore generally expected.

Given that neither speed nor memory need to be considered here, optimisations as you seem to expect them do not take place here.

Answer 2

This is best answered by the authors of the JavaScript engines.

It's a process called performance tuning.

Here's Google's guide. Here's Mozilla's guide.

Making Node.js run javascript fast is the core of Strongloop's business. They take javascript optimization seriously.

There's a few gotchas like this.

Mostly though, don't block the event loop - use promises, async operations, callbacks, etc.

Benchmark your code with reasonable realistic test cases. Make sure to check coverage.

Once you get down to the main cause of your search for performance tuning, you have to start digging deeper. You have to profile your code.

Thorsten Lorenz has an aging but still mostly relevant GitHub repository that contains a lot of useful insider V8 info.

There's lots of developers that post blog articles, like this guy. You have to make sure they know what they're talking about. He does.

Bluebird, a notoriously well performing implementation of Promises, is a pinnacle of correct optimization. They have an article and a guide on things that they've noted that are simply common things that kill optimization.

Update

The example you gave of the util.s implementation an inheritance chain should probably be a separate question. I'm not sure if they're monkey patching there, I'd have to see the rest of the class and prototypes.

See this MDN article for the pros and cons and variations of known ways to implement inheritance, specifically for the use of Object.create, but the others as well.

The only good reason for extending a built-in prototype _{(aka "monkey patching")} is to backport the features of newer JavaScript engines; for example Array.forEach, etc.

Here's some reasoning on why this kind of thing is done. I answered a question not too long ago about injecting a class into the top of an inheritance chain for the purpose of adding an extension method to all of their children. It's not a great idea.

Turns out, Object.create in the util.js implementation of inherits may have been an attempt at optimization originally. According to early revisions, it made the prototype implicitly immutable, theoretically improving method resolution performance. Pedantically speaking, it was never correct, and has always been essentially a hack around the prototypal inheritance capabilities of JavaScript. New revisions replace this with Object.setPrototypeOf.

Edit: If you down-voted this, I would appreciate a glimpse of why.