Use Recursion to Create a Range of Numbers

Hello.

I just finished the Basic Javascript stage and came up with two different solutions for the the Use Recursion to Create a Range of Numbers, and I was wondering which solution would be preferable.

Here are the solutions:

// Solution #1
function rangeOfNumbers(startNum, endNum) {
  if (startNum > endNum) {
    return [];
  } else {
    return rangeOfNumbers(startNum, endNum - 1).concat(endNum);
  }
};
// Solution #2
function rangeOfNumbers(startNum, endNum) {
  if (startNum > endNum) {
    return [];
  } else {
    const arr = rangeOfNumbers(startNum, endNum - 1)
    arr.push(endNum)
    return arr;
  }
};

They’re basically using the same idea, but one uses concat() and the other uses push().

Since push() adds the element to the end of the array and returns the length, I had to declare the variable arr, and thus the solution consists of more lines.

However, according to MDN:

The concat() method is used to merge two or more arrays. This method does not change the existing arrays, but instead returns a new array.

So I was wondering if this consecutive creation of new arrays imposes a bigger load when executed compared to using push()?

If you were doing a massive amount of this with very big arrays then it might be worth doing some benchmarking on different brower/OS combinations to see if there is a difference. But for the most part you shouldn’t worry about this at all and you should go with the code you think is better (i.e. more readable) for the situation you are a coding for.

As for your question, it probably depends on the browser/OS combination as to which one is “better” for performance (if there really is a substantial difference). Also, javascript engines are highly optimized and can analyze your code and optimize for efficiency. So even if you use one method the JS engine may decide to do it differently anyway. But if you are curious, I’m sure you could easily set up some tests and then run them on various browsers to see which one is more efficient. I’d be interested to know what you find.

1 Like

One line recursive step without concat.
In ES6 section will be related lessons

function rangeOfNumbers(startNum, endNum) {
  if (startNum > endNum) {
    return [];
  } else {
    return [...rangeOfNumbers(startNum, endNum - 1), endNum]
  }
};

console.log(rangeOfNumbers(2, 7))//[ 2, 3, 4, 5, 6, 7 ]

Since concat creates a new array I would expect it to have some more overhead than push, but as @bbsmooth says, test it and see!

1 Like

Ya, my testing is showing that the push version of this function is blowing the concat version out of the water, especially as the range you generate gets bigger. So if you really want to use recursion to find a range of numbers (which you don’t :slight_smile: ) especially if the range has the potential to be large, then you definitely want to use the push version. I guess this is a case where testing does pay off.

1 Like

Your spread syntax version isn’t quite as bad as the concat version but it is still nowhere near as good as the push version, especially as the range gets bigger. Stick with the push version :slight_smile:

2 Likes

As I understand it, with push we ALWAYS will have one array here in this function. With each recursive step array just will grow a little, element by element.
We will end up with array of perfect length for our needs, no less ,no more.

Concat will spam for us bunch of arrays. One array for each recursive step.

1 Like

@bbsmooth,

Thank you for testing them out! I don’t know how to test program performance myself quite yet, but I’m sure I can find something:)

It’s interesting to see how one function can change the performance of the process and how the difference is minute at small data sizes, but grows as batch size increases. I’ll stick with the push() version for this one:D

@admit8490,

Thanks, I’ll check it out! Starting ES6 section today:)

Yeah and I was aware that push() doesn’t create additional arrays and concat() does each iteration, but I wanted to see if there was a substantial difference in performance that would affect our choice of code, which there is.