Let's start with string concatenation. Take a look at the following code snippet:

    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);

The preceding snippet contains a simple function createString, which returns a long string, precisely 617 characters long. We append this string to itself 40,000 times. In the first loop, s1 does so by calling s1.concact(createString()) as many times, and in the second loop, s2 does so by calling s2+= createString() as many times. This is just a shorthand for s2 = s2 + createString().

When you analyze these loops, how long do you think they took to complete execution? Did one substantially outperform the other? Or, do you think they're just two different ways to append a string to itself, and has no impact on performance? Well, here are the results:

The preceding results are an average of five runs. As you can clearly see, Loop 1 outperforms Loop 2 massively.

Just to understand how massive the impact on the end result would be, consider the following scenario. Consider a social web application, which when the user starts on his/her end loads the entire friend/contact list and the entire conversation history with each contact. Hypothetically, assume that the user has 100 contacts, and with each contact he/she has 10 conversations. Let's further assume each conversation to be essentially the preceding string in our example appended to itself 40,000 times. Using our preceding results (considering Chrome as the web browser), with an inefficient implementation of string concatenation the page load time would be 100 * 10 * 60 milliseconds = 60,000 milliseconds = 60 seconds or 1 minute. Now, that's a really long time the user has to wait before the application becomes functional. Such sluggishness can greatly impact the application's usability and user engagement.

As opposed to this, if the user was to load the same application with the efficient string concatenation technique, the user wait time would be 100 * 10 * 7 = 7,000 milliseconds = 7 seconds, which is not quite that bad.

If you're starting to appreciate the powers of efficient implementation, we're just getting started. The time performance isn't even the critical impact factor. The resource that is greatly impacted is memory!

When you do s1.concact(createString()), you're essentially appending the string on the same object, as a result of this the total memory consumption is increased only by the memory needed by the additionally appended string.

However, when you do s2+= createString(), you're essentially creating a new object each time. If s2 was pointing to a memory block which occupies x bytes, now after one call to s2+= createString(), it is pointing to a new memory block which occupies x + x = 2x bytes. Thus, at each step, the total memory consumption is greatly increased.

After 40,000 such invocations, the first loop will result in total memory consumption of 40,000 * x bytes, whereas the second loop will result in total memory consumption of x + 2x + 3x + ... + 40,000 * x bytes = 800, 020 * x bytes. As you can see, way greater memory is consumed by the second loop.

Running some tests, it is observed that on Chrome, the shallow size occupied by the concatenated string during the execution of the first loop is 802, 160 bytes, or ~0.8 MB. The shallow size occupied by the concatenated string during the execution of the second loop is 8, 002, 160 bytes, or ~8 MB.

The implications of this are dastardly, and the user can experience application crashes and freezes due to memory overload, which would lead to poor user experience and if not immediately corrected, very soon zero usability and lost business.

Now, let's take a look at string replacement.

Take a look at the following code snippet:

    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);

In the preceding code snippet, we start with the same base string as in previous examples. Here, we have the objective of replacing every whitespace with the pipe character ('|'). For example, if the base string were "High Performance TypeScript", after applying our replace logic, the resultant string would be "High|Performance|TypeScript".

Now, this string has a total of 127 whitespaces. We loop over the base string and perform this replacement a total of 50,000 times. Let's understand the following two different replacement options we are leveraging:

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

Let's split this into two pieces to better understand how this works, such as split and join:

        baseString.replace(/ /g, replacementCharacter);

The replace method returns a new string with some or all matches of a pattern replaced by a replacement character. We again choose the pipe character as the replacement character, and the pattern we choose is a regular expression '/ /g'. We specify a RegEx by enclosing it within the forward slash character ('/'). Here, we specify a white space as the RegEx.

If you were to analyze the two methods, you would note that in the SplitJoin method you perform two passes around the input string -- first to break it down into smaller chunks, and then to combine those chunks back into a whole string. This would involve as many string concatenations as the number of chunks it got split into in the first place. The Replace with RegEx options seems to take one pass around the input string, creating a new string copy, character by character, looking for a pattern match along the way and replacing it with the replacement character. An educated guess would be that the Replace with RegEx option has a better performance.

Let's take a look at the results to find out! Note that these are a result of 127 replacements on a 617 character long string, done 50,000 times:

As we predicted, the Replace with the RegEx method outperforms the SplitJoin method. The difference between the two methods is more significant on IE and Edge. In terms of real-world usage, string replacement is even more widely used than concatenation. Any web/mobile application with a frontend framework that works with multiple backends, or even a single backend, can run into the string replacement scenarios where data interpretation across different systems varies and there's a need to replace some strings to convert it into a format that the current system can understand. If done inefficiently, the results could once again lead to a slower/sluggish UI rendering, higher network latencies, incapability in using the application's full feature set due to the slower performance making the application unusable and gives you a poor user experience overall.

As you can see, efficient implementation of basic data type manipulations have a far reaching impact on the performance and usability of an application. Let's look at some other data structures and constructs.