Are Typescript objects slower in performance by combining their methods?

I could be wrong, but after looking at the typescript playground I noticed that they are bundling their classe methods together with an object variable, which feels like it might degrade performance every time I call a new object.

eg. Typescript Class playing field output

var FatObject = (function () {
   function FatObject(thing) {
       this.objectProperty = 'string';
       this.anotherProp = thing;
   }
   FatObject.prototype.someMassivMethod = function () {
       //many lines of code 
       //...
       //...
       //...
       //.......................
    };
   return FatObject;
}());

var thing = 'example';
var objOne = new FatObject(thing);
var objTwo = new FatObject(thing);
var objThree = new FatObject(thing);
var objFour = new FatObject(thing);

      

I feel that if I write massive methods, every time I create a new object from the class, I will also compile those massive methods.

Instead of declaring methods outside the function name when creating new objects.

eg. old way:

function ThinObj(thing) {
    this.anotherProp = thing;
    this.objectProperty = 'string';
}

ThinObj.prototype.someMassivMethod = function() {
    //many lines of code 
    //...
    //...
    //...
    //..................
}

const thing = 'example'
let objOne = new ThinObj(thing);
let objTwo = new ThinObj(thing);
let objThree = new ThinObj(thing);
let objFour = new ThinObj(thing);

      

Can anyone clarify if:

A: I'm loading 4 types of functions into memory in the Typescript example (or overwriting them since the prototype is in use - I'm still shaking my understanding of prototype).

Q: If more compiler work is going on with Typescript wrapping methods together?

thank

+4


source to share


1 answer


Closing is only done when the class is created. This is called an invocation function expression (IIFE) and can be recognized by the characteristic ())

or )()

after the function is closed }

.

This means that it is executed only once and therefore you have nothing to fear from it in terms of performance (in general, functions are cheaper than people think anyway).

Also, this class generation pattern is generic and idiomatic as it encapsulates a class definition in a single expression.

It is also important to properly redeploy classes that are not a TypeScript function but an ECMAScript function. According to the ES2015 spec (the standard that added the class function) the class definitions were not raised, but the function definitions have always been, so the correct translation is indeed the assignment of the IIFE result to the value var

.

To illustrate this in code:



console.log(ThinObj);
// Does not cause an error and thus violates the specification for ES2015 classes
var t = new ThinObj('thing'); // Succeeds because function is hoisted

function ThinObj(thing) {
  this.thing = thing;
}
      

Run codeHide result


against

console.log(ThinObj);
// Causes an error and therefore complies with the specification for ES2015 classes
var t = new ThinObj('thing'); // Fails because var is `undefined` before initialization

var ThinObj = (function ThinObj() {
  function ThinObj(thing) {
    this.thing = thing;
  }
  return ThinObj;
}());
      

Run codeHide result


+4


source







All Articles