TypeScript High Performance

Let's start by taking a look at strings. In TypeScript, you can create a string in one of the following ways:

    var test1: string = 'test string';

    var test2: String = new String('test string');

For all practical purposes, you would almost always use the first way to work with strings. The only difference between the two is that string is a literal type and a preferred way to declare strings in TypeScript. String is an object type, which is essentially a wrapper object around the string. From a performance standpoint, literal types tend to perform better than object types. We can confirm this by running a simple code snippet as mentioned in the following code snippet:

    function createString_1(): string {
     return `Lorem Ipsum is simply dummy text of the printing and  
     typesetting industry. Lorem Ipsum has been the industry''s    
     standard dummy text ever since the 1500s, when an unknown    
     printer took a galley of type and scrambled it to make a type   
     specimen book. It has survived not only five centuries, but also      
     the leap into electronic typesetting, remaining essentially  
     unchanged.It was popularised in the 1960s with the release of   
     Letraset sheets containing Lorem Ipsum passages, and more  
     recently with desktop publishing software like Aldus PageMaker   
     including versions of Lorem Ipsum.`;
    }

    function createString_2(): String {
     return new String(`Lorem Ipsum is simply dummy text of the   
     printing and typesetting industry. Lorem Ipsum has been the 
     industry''s standard dummy text ever since the 1500s, when an   
     unknown printer took a galley of type and scrambled it to make a  
     type specimen book. It has survived not only five centuries, but 
     also the leap into electronic typesetting, remaining essentially  
     unchanged. It was popularised in the 1960s with the release of  
     Letraset sheets containing Lorem Ipsum passages, and more 
     recently with desktop publishing software like Aldus PageMaker 
     including versions of Lorem Ipsum.`);
    }

    // calculate time taken to create 50, 000 'strings'
    let time1: number = Date.now();
    for (let i = 0; i < 50000; i++) {
      createString_1();
    }

    let time2: number = Date.now();
    console.log('Time difference (createString_1): ', time2 - time1);

    // calculate time taken to create 50, 000 'Strings'
    time1 = Date.now();
    for (let i = 0; i < 50000; i++) {
      createString_2();
    }

    time2 = Date.now();
    console.log('Time difference (createString_2): ', time2 - time1);

The preceding code snippet creates a long string (the famous filler text mostly used as a placeholder on visual web elements) using the preceding described two ways.

Now, let's take a look at the results of executing the preceding code snippet:

As you can see from the results, the literal type string does behave slightly better. The creation of the string, however, is not the most impacting operation that would affect your application. Let's take a look at some classic string manipulation operations.

    function createString(): string {
     return `Lorem Ipsum is simply dummy text of the printing and 
     typesetting industry. Lorem Ipsum has been the industry''s 
     standard dummy text ever since the 1500s, when an unknown   
     printer took a galley of type and scrambled it to make a type     
     specimen book. It has survived not only five centuries, but also 
     the leap into electronic typesetting, remaining essentially  
     unchanged. It was popularised in the 1960s with the release of 
     Letraset sheets containing Lorem Ipsum passages, and more 
     recently with desktop publishing software like Aldus PageMaker   
     including versions of Lorem Ipsum.`;
    }

    let time1: number = Date.now();
    let s1: string = '';

    for (let i = 0; i < 40000; i++) {
     s1 = s1.concat(createString());
    }

    let time2: number = Date.now();
    console.log('Time difference: ', time2 - time1);

    let s2: string = '';
    time1 = Date.now();

    for (let i = 0; i < 400000; i++) {
     s2 += createString();
    }

    time2 = Date.now();
    console.log('Time difference: ', time2 - time1);

    function createString(): string {
      return `Lorem Ipsum is simply dummy text of the printing and     
      typesetting industry. Lorem Ipsum has been the industry''s  
      standard dummy text ever since the 1500s, when an unknown   
      printer took a galley of type and scrambled it to make a type  
      specimen book. It has survived not only five centuries, but 
      also the leap into electronic typesetting, remaining   
      essentially unchanged. It was popularised in the 1960s with the   
      release of Letraset sheets containing Lorem Ipsum passages, and   
      more recently with desktop publishing software like Aldus  
      PageMaker including versions of Lorem Ipsum.`;
    }
    let baseString: string = createString();
    const replacementCharacter: string = '|';
    let time1: number = Date.now();
    for (let i = 0; i < 50000; i++) {
        baseString.split(' ').join(replacementCharacter);
      }
    let time2: number = Date.now();
    console.log('Time difference (SplitJoin): ', time2 - time1);
    time1 = Date.now();
    for (let i = 0; i < 50000; i++) {
         baseString.replace(/ /g , replacementCharacter);
        }
    time2 = Date.now();
    console.log('Time difference (Replace_w_RegExp): ', time2 - 
    time1);

        baseString.split(' ').join(replacementCharacter);

        baseString.replace(/ /g, replacementCharacter);

For folks acquainted with object-oriented concepts, the use of classes and interfaces is well known. It is the most basic way to encapsulate information. Classes encapsulate a common data schema, and operations for all of its instances, and interfaces just encapsulate a schema which needs to be implemented by any class that implements the interface.

These are the basics which you must already be familiar with. Instead of introducing some simple examples of class and interface declaration, let's deep dive into an advanced usage scenario, very close to how real-world modern web/mobile applications are structured. Pay close attention to the following problem statement.

Let's assume we are a vendor company for another firm, lets say XYZ. Now, XYZ contacts us and asks us to implement Social Network Feed Generator(SNFG). XYZ is building an application to combine social network feed from all possible social networks, and displays this aggregated feed to it's users. Let's assume a scenario in which a single universal key or token that can authenticate a user against all of his/her social networks (let's not worry about the security at this moment, as we are not trying to understand cryptography here!). XYZ plans to pass us this key for it's users, and in return, wants an aggregated feed based on several different criteria such as most recent updates, most popular updates, and so on. Now, our job is simple --to provide an API to XYZ that it can use in it's application.

Let's get started building SNFG in an object-oriented way, making it extensible for future updates. Take a look at the following code snippet:

     // publicly accessible
     export enum FeedStrategy { Recent, Popular, MediaOnly };

     // internal
     enum SocialMediaPlatform { Facebook, Instagaram, Snapchat, 
     Twitter, StackOverflow };

     // publicly accessible
     export interface IFeed {
        platformId: SocialMediaPlatform;
        content: string;
        media: string
     }

     // publicly accessible
     export interface IFeedGenerator {
         getFeed(limit?: number): IFeed[];
     }

     // internal
     class RecentFeedGenerator implements IFeedGenerator {
       private authenticate(universalKey: string): void {
         // autheticate user identity
     }

     public getFeed(limit?: number): IFeed[] {
      /* if authenticated
       {
          custom algorithm to optimally calculate most recent social 
          media feed for the user, across all the available social 
          media platforms
       } */
        return []; /* return the results, returning empty array here to     
        satisfy method return type */
      }
     }

     // internal
     class PopularFeedGenerator implements IFeedGenerator {
       private authenticate(universalKey: string): void {
        // autheticate user identity
      }

     public getFeed(limit?: number): IFeed[] {
     /* if authenticated
        {
           custom algorithm to optimally calculate most popular  
           social media feed for the user, across all the available   
           social media platforms
        } */
       return []; /* return the results, returning empty array here to  
       satisfy method return type */
     }
    }

     /* you can have as many classes as you desire, or you can also  
     combine  multiple feed fetching algorithms into single class */

     // publicly accessible
     export function FeedGeneratorFactory(feedStrategy: FeedStrategy,  
     universalKey: string): IFeedGenerator {
       let feedGenerator: IFeedGenerator = null;
       switch (feedStrategy) {
          case FeedStrategy.Recent: {
             feedGenerator = new RecentFeedGenerator();
          break;
        }
          case FeedStrategy.Popular: {
             feedGenerator = new RecentFeedGenerator();
          break;
        }
      }
      return feedGenerator;
     }

We design a module called Feeder (we will be looking at modules and namespaces in closer details in the next chapter). Within this module, we build the crux of our SNFG. The idea is that XYZ can use the exported members (publicly accessible) of this module to achieve its objective. Let's take a look at the exported members of Feeder in the following code snippet:

    export enum FeedStrategy { Recent, Popular, MediaOnly };

    export interface IFeed { ... };

    export interface IFeedGenerator { ... };

    export function FeedGeneratorFactory(feedStrategy: FeedStrategy,  
    universalKey: string): IFeedGenerator { ... }

The most important exported function is FeedGeneratorFactory. XYZ can call this function with it's desired FeedStrategy (which is also exposed as an enum), and universalKey for the user it wishes to access the feed of. With this information, what FeedGeneratorFactory does is completely abstracted. This function returns an interface type IFeedGenerator. This is all that the developers of XYZ should really care about. We expose an interface IFeedGenerator, any class implementing which implements the function getFeed which takes in an optional limit parameter to specify the upper limit on the number of desired feed items. From XYZ's perspective, they can simply invoke the FeedGeneratorFactory function, and call the getFeed() function on the returned IFeedGenerator implementation. Internally, based on the FeedStrategy function, we return a different class. We could as well have put all of the logic into a single class (although not a good idea). How we implement this is completely up to us and is hidden from XYZ.

The feed method returns an array of IFeed type, which is also an exposed interface. Each IFeed consists of platformId to identify the social media platform the feed belongs to, a string content, and string media, which is a URI pointing to the media used in the feed, if any. The contents of IFeed can be discussed with XYZ and modified if needed.

All other members, such as the actual classes implementing the core logic of feed fetch, sort, organize, most likely cache, and several other concepts which would need to be introduced as the scale of this increases, are internal to us and totally abstracted from XYZ.

Now from XYZ's perspective, knowing this information, all they need to do is import our module and use it in their application. One possible usage could be as illustrated in the following code snippet:

    import * as Feeder from "./vendor";

    class FeedRenderer {
      private recentFeedGenerator: Feeder.IFeedGenerator;
      private popularFeedGenerator: Feeder.IFeedGenerator;

      constructor(universalKey: string) {
        this.recentFeedGenerator = Feeder.FeedGeneratorFactory 
        (Feeder.FeedStrategy.Recent, universalKey);
        this.popularFeedGenerator = Feeder.FeedGeneratorFactory
        (Feeder.FeedStrategy.Popular, universalKey);
       }

     public getRecentFeed(): Feeder.IFeed[] {
      return this.recentFeedGenerator && this.recentFeedGenerator
      .getFeed();
    }

     public getPopularFeed(): Feeder.IFeed[] {
      return this.popularFeedGenerator &&   
      this.popularFeedGenerator.getFeed(10);
   }
}

There are several ways to import and export modules, which we will explore in the next chapter. In the preceding example, we are explicitly including a reference to the vendor.ts file which we looked at earlier.

With this setup, XYZ gets access to the exposed members of our Feeder module. They simply call the FeedGeneratorFactory function to get access to two IFeedGenerator types, such as one that fetches the most recent feeds, and one that fetches the most popular feeds. From their standpoint, they don't really care whether it's the same implementation or two different implementations under the wraps. All they care is, it is of the type IFeedGenerator. The FeedRenderer class would be called into by XYZ's UI elements to render the fetched feed.

The following diagram summarizes the factory pattern we've been discussing thus far:

Apart from the flexibility this offers to you as a vendor, in terms of internally managing the concrete implementations, it also makes it easier for you to manage version updates and rollbacks. Any new releases can be rolled out without breaking the consumer contract (explicit consumer-driven contracts can be enforced too), and if anything were to break, you can rollback to an earlier version, and the experience from the consumer's perspective would be seamless.

This helps the consumer as well, in that if the preceding exposes API, becomes or is an industry standard, and there are multiple such vendors available to choose from in the market, the consumer can seamlessly switch between multiple vendors without having to make major changes to their core code base.

As you can see, when leveraged wisely, classes and interfaces can have a high impact on the longevity and scalability of your application, and consequently on it's performance.

Loops are one of the most common constructs in any language. It is a mechanism to execute the same piece of logic multiple times. There are multiple ways to do so in TypeScript. Let's take a look at some in the following code snippet:

    const arr: Array<number> = [];
    let temp: number = 0;

    const randomizeArray = () => {
      for (let i = 0; i < 50000; i++) {
          arr[i] = Math.floor(Math.random() * 100000);
        }
     }

    // dummy method
    const dummy = () => null;

    // for...in
    const forinLoop = () => {
      let dummy: number;
      for (let i in arr) {
          dummy = arr[i];
        }
     }

    // for...of
    const forofLoop = () => {
       let dummy: number;
       for (let i of arr) {
       dummy = i;
      }
    }

    // naive
    const naiveLoop = () => {
       let dummy: number;
       for (let i = 0; i < arr.length; i++) {
          dummy = arr[i];
       }
    }

    const calculateTimeDifference = (func: () => void): number => {
       randomizeArray();
       const time1: number = Date.now();
       func();
       const time2: number = Date.now();
       return time2 - time1;
    }

    console.log('Time Difference (forof): ', calculateTimeDifference
    (forofLoop));
    console.log('Time Difference (forin): ', calculateTimeDifference
    (forinLoop));
    console.log('Time Difference (naive): ', calculateTimeDifference
    (naiveLoop));

In the preceding code snippet, we declare an array arr. We initialize it with 50,000 random numbers. Then, we measure the time performance of three loops such as forof loop, forin loop, and naive loop. Before we dig into the performance results, let's take a look at a side note on the syntax.

Let's take a look at the following performance of these loops now:

As can be seen, the forof loop performs the best, followed by naive loop, followed by the forin loop. These results are actually a little misleading. For one, the performance of the naive loop can be greatly improved by storing the arr.length property in a variable and using that in the loop statement, instead of accessing the array's property each time. In addition to that, the preceding example is not really a strong case in point for the forin loop. Let's take a look at another example which would highlight the advantages of using the forin loop:

    const calculateTimeDifference = (func: () => void): number => {
     const time1: number = Date.now();
     func();
     const time2: number = Date.now();
     return time2 - time1;
    }

    const generateGuid = (): string => {
     return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g,  
     (c: string) => {
     const r = Math.random() * 16 | 0,
     v = c == 'x' ? r : (r & 0x3 | 0x8);
     return v.toString(16);
     });
    }

    interface Map {
       [key: string]: string;
     }

    const map: Map = {};

    for (let i = 0; i < 50000; i++) {
         map[(i+1).toString()] = generateGuid();
       }

    // for...in
    const mapForIn = () => {
     let dummy: string;
     for (let key in map) {
         dummy = key;
       }
   }

    // for...of
    const mapForOf = () => {
        let dummy: string;
        const keys = Object.keys(map);
        for (let key of keys) {
          dummy = key;
       }
    }

    // naive
    const mapForNaive = () => {
      let dummy: string;
      const keys = Object.keys(map);
      for (let i = 0; i < 50000; i++) {
         dummy = keys[i];
     }
    }

    console.log('Time Difference (map:forof): ',  
    calculateTimeDifference(mapForOf));
    console.log('Time Difference (map:forin): ', 
    calculateTimeDifference(mapForIn));
    console.log('Time Difference (map:naive): ', 
    calculateTimeDifference(mapForNaive));

The preceding code snippet generates the following result:

On Chrome, the forof loop outperformed the forin loop, but only slightly. On IE and Edge, the forin loop recorded the best performance, while the naive loop remained the least efficient across all browsers. Thus clearly, the forin loop is the recommended for looping over objects such as dictionaries. Based on the use case, one should choose the option that most makes sense.

Conditional statements are one of the most commonly used constructs in any language. In TypeScript, you may implement a conditional using the if..else statement or the switch…case statement. Let's take a look at these constructs.

Consider the following if..else block:

    let decision: number = Math.floor(Math.random() * 100) + 1; //  
    random // number between 1 and 100
    if(decision === 1) {
        // do something
     } else if(decision === 2) {
        // do something
     } else if (decision === 3) {
     // do something
     } else if (decision === 4) {
     // do something
     } else if (decision === 5) {
    // do something
     } else if (decision === 6) {
     // do something
     } else if (decision === 7) {
     // do something
     } // ...
       // ...
       // ...
     } else (decision === 100) {
     // do something
     }

The performance of the preceding code block would be the worst if decision is 100, making 100 comparisons before our condition evaluates to true. If you notice, this if..else chain is equivalent to a linear search, the time complexity of which in terms of Big-Oh notation is O(n) where n is the total number of comparisons. In the worst case, you would make n comparisons like in the preceding example. In the best case, the very first comparison would evaluate to true. On average you would make n/2 comparisons. If you have data points with the probability of different values that decision can take, you can optimize the preceding if..else chain by making the higher probability comparisons before the others. The time complexity of this optimized approach would still be O(n).

In order to improve the performance in a generic case, especially when the probabilities are unknown, you can refactor the if..else chain to reflect binary search. In binary search, you eliminate half of the choices at each stage, thereby yielding a logarithmic time complexity O(lg_n). Look at the following code snippet to get a better idea:

    let decision: number = Math.floor(Math.random() * 100) + 1; //     
    random // number between 1 and 100
    if (decision < 50) {
         if (decision < 25) {
             if (decision < 12) {
                 if (decision < 6) {
                     // all results < 6
                       if (decision < 3) {
     // compare decision with 1 and 2
     } else {
     // compare decision with 3, 4 and 5
            }
           } else {
           // all results >=6 and < 12
           if (decision < 10) {
                if (decision < 8) {
                     // compare decision with 6 and 7
                } else {
                         // compare decision with 8 and 9
                       }
                     } else {
                              // compare decision with 10 and 11
                            }
                       }
                      } else { /* ... */ }
                      } else { /* ... */ }
                      } else { /* ... */ }

One thing that would strike you immediately with the preceding code snippet is that even though it performs better than the linear checks, it's readability is a big pain. Code maintenance is a big factor that would be impacted especially when working on large team projects. It's a good time to look at the switch…case statement:

    let decision: number = Math.floor(Math.random() * 100) + 1; //  
    random // number between 1 and 100
    switch (decision) {
     case 1: {
        // do something
     break;
       }
     case 2: {
       // do something
     break;
       }
       // ...
      // ...
     case 100: {
     // do something
     break;
     }
     default: {
      // do something
     }
    }

On first look, the switch…case statement seems to be similar to the linear if..else block. However, it is internally based on the browser you're running the script on, the rendering engine would optimize the number of comparisons. Given this fact combined with a much better code readability, you should choose the switch…case statement whenever you can make single value comparisons.

In TypeScript, you can declare arrays using the classic square bracket syntax, for example, let arr: number[] = [74, 46, 32]; or, you can also declare arrays using the Array<elementType> syntax, for example, let arr: Array<number> = [74, 46, 32];.

Let's take a look at a sorting example with arrays:

    const arr: number[] = [];
    let temp: number = 0;

    const randomizeArray = () => {
       for (let i = 0; i < 50000; i++) {
           arr[i] = Math.floor(Math.random() * 100000);
          }
       }

    // naive
    const naiveSort = () => {
     for (let i = 0; i < arr.length; i++) {
         for (let j = 0; j < arr.length - 1; j++) {
             if (arr[j] > arr[j + 1]) {
                   temp = arr[j];
                   arr[j] = arr[j + 1];
                   arr[j + 1] = temp;
                 }
              }
          }
      }

    // optimized
    const optimizedSort = () => {
     let swapped: boolean = true;
     while (swapped) {
           for (let j = 0; j < arr.length - 1; j++) {
                   swapped = false;
               if (arr[j] > arr[j + 1]) {
                        swapped = true;
                        temp = arr[j];
                        arr[j] = arr[j + 1];
                        arr[j + 1] = temp;
                      }
                   }
               }
          }

    const calculateTimeDifference = (func: () => void): number => {
        randomizeArray();
        const time1: number = Date.now();
        func();
        const time2: number = Date.now();
        return time2 - time1;
      }

In the preceding code snippet, we declare an array and initialize it with 50,000 elements, each of which is a random number between 0 and 100,000. The sorting algorithm we're looking at is bubble sort. Bubble sort works by bubbling the largest element to the end of the array in each pass (assuming a non-decreasing sort).

The number of passes needed by this algorithm is one less than the number of elements. Let's take a look at the following diagram to get a better idea:

As you can see in the preceding diagram, we start with a 6 element array. In Pass 1, we make four comparisons starting from the first element, and performing a swap each time we detect an order mismatch. For example, 87 > 12, which is a mismatch and hence we do a swap. 87 > 45, so we swap again. 87 < 93, and so we do not swap. Finally 93 > 16 and 99 > 93, so we swap. At the end of Pass 1, we ensure that the largest element is at the end of the array.

We perform four more such passes, ensuring that the largest element during that pass ends up toward the end of the array.

Generalizing this for an n-element array, we can see that the total comparisons we will end up making is (n-1)*(n-1), which when talking in terms of Big-Oh gives us a time complexity of O(n²).

The preceding concept is implemented in the preceding code snippet under the function naiveSort. While reading this, you may have already detected an inefficiency in the preceding approach. We need not have (n-1) passes by rule of thumb. As you can see at the end of Pass 4, we already have a sorted array and do not really need Pass 5. So, when do we know when to stop? Answer: When there was no swap performed during a pass we stop. This optimized approach is implemented in the preceding code snippet under the function optimizedSort.

The results, not surprisingly, are as follows:

As you can see, a simple optimization has massive impacts on performance. On Chrome, it outperforms the naive implementation by gigantic amounts. The optimized sort runs as fast as a millisecond! And the naive sort takes almost 8 seconds! On IE and Edge, the findings are even more dire. As expected, the optimized sort runs fairly quickly. However, the naive sort never completes and the web page crashes even before the sort can complete!

Once again, the time performance despite having contrasting comparison is not the most critical factor. CPU utilization and to some extent memory consumption are the resources most severely impacted. Just to give you some context, the average CPU utilization for a web page running advanced chat applications is only 0.5-3%. However, when the preceding script is executed on a web page, the CPU utilization shoots up to 30-35%! This is one of the reasons why the web page crashes. Note that the preceding percentage values are on a two core processor with a maximum speed of 2.81 GHz.

There are several web/mobile applications that may perform the sorting of such a massive scale. Consider a travel booking application for instance. Among the several thousand options, different levels of sorting are performed, sorting based on prices, timings, and so on. An optimal algorithm powering these sorts is of vital importance. Any inefficiency will manifest itself as either UI spinners spinning forever, or application/web page crashes. Either of these scenarios would take a massive hit on your application's user engagement and ultimately on your business.

Let's now take a look at the several available operators you can leverage in TypeScript. Quite a few have already been implicitly introduced to you via code snippets from previous sections. Let's formally declare all the operators:

        const x: number = 9/4; //evaluates to 2.25

        const y: number = 9%4; // evaluates to 1

As the usage of the remaining operators is natural, let's look at the next class of operators.

        const condition: boolean = x > 0 && x < 10; // simple   
        condition AND

        this.instanceVariable && this.instanceVariable.DoOperation(); 
        /* AND used to check for non-null instance variable, and then    
        perform the operation on that instance. */

        // This could also be written as

        if (this.instanceVariable) { 
             this.instanceVariable.DoOperation(); 
         }

For the sake of completeness, lets also explore the typeof operator, instanceof operator, and Compound AssignmentOperators with the help of the following code snippet:

        // 1. compound assignments
        let num: number = 40;
        num *= 2; // num1 equals 80. this is same as num = num * 2

        // 2. typeof
        const str: String = 'test';
        console.log(typeof num); // outputs number
        console.log(typeof str === 'string'); // outputs true

        // 3. instanceof
        const arr: number[] = [1,2,3];
        class ABC {};
        const abc: ABC = new ABC();

        console.log(arr instanceof Object); // outputs true
        console.log(arr instanceof Array); // outputs true
        console.log(abc instanceof Object); // outputs true
        console.log(abc instanceof ABC); // outputs true
        console.log(arr instanceof ABC); // outputs false

Thus, writing num *= 2 is equivalent to writing num = num *2. Similar to compound multiplication assignment, we can have compound addition, subtraction, and division assignments. Take a look at the following operators:

In this chapter, we looked at some basic data structures, constructs, and algorithms, and explored the performance impact of leveraging these in an efficient manner. We understood how these performance tweaks play a major role toward the durability, scalability, maintainability, and the performance of your application.

After exploring these basic constructs, let's take a look at some declaration basics that TypeScript offers in our next chapter.