Benchmark: Testing leftpad just for lulz

Script Preparation code:

function randstring() {
  const l = Math.ceil(Math.random()*16+5)
  const alphabet = "abcdefghijklmnopqrstuvwxyz"
  let a = []
  for (let i=0; i<l; i++) {
     a.push(alphabet[Math.floor(Math.random()*alphabet.length)])
  }
  
  return a.join("")
}

var strings = []
var numbers = []
for (let i=0; i<100; i++) {
  strings.push(randstring())
  numbers.push(Math.floor(Math.random()*10000))
}
var testdata = [strings, numbers]

var leftpad1 = function(str, len, ch) {
  str = str.toString();
  var i = -1;
  if (!ch && ch !== 0) ch = ' ';
  len = len - str.length;
  while (++i < len) {
    str = ch + str;
  }
  return str;
}

var leftpad2 = function(str, len, ch) {
  str = str.toString()
  if (str.length >= len) return str
  
  ch = !ch && ch !== 0 ? " " : ch
  return ch.repeat(len-str.length) + str
}

Tests:

Old npm leftpad
let result = testdata.map( (data) => data.map( (value) => leftpad1(value, 50)))
string repeat
let result = testdata.map( (data) => data.map( (value) => leftpad2(value, 50)))
Built-in method
let result = testdata.map( (data) => data.map( (value) => value.toString().padStart(50)))

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Old npm leftpad
string repeat
Built-in method

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: one year ago)

User agent: Mozilla/5.0 (Android 10; Mobile; rv:132.0) Gecko/132.0 Firefox/132.0

Browser/OS: Firefox Mobile 132 on Android

View result in a separate tab

Test name	Executions per second
Old npm leftpad	1746.0 Ops/sec
string repeat	5115.9 Ops/sec
Built-in method	5021.3 Ops/sec

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):

LLMs can make mistakes. Check important info.

**What is being tested?**

The provided JSON represents a JavaScript benchmark that tests three different approaches to padding strings with a specified character:

1. **Leftpad function (leftpad1)**: This function takes a string `str`, a length `len`, and an optional character `ch` as input. It appends the character to the beginning of the string until it reaches the desired length.
2. **String repeat function (leftpad2)**: This function takes a string `str`, a length `len`, and an optional character `ch` as input. If the string is already longer than or equal to the desired length, it returns the original string. Otherwise, it repeats the character `ch` to fill the remaining length.
3. **Built-in padStart method**: This approach uses the built-in `padStart()` method on the JavaScript string prototype, which pads a string with characters from the start of the specified string until it reaches the desired length.

**Options compared**

The benchmark compares the performance of these three approaches:

* **Leftpad function (leftpad1)**: This approach is likely slower because it involves appending characters to the beginning of the string, which can be inefficient.
* **String repeat function (leftpad2)**: This approach might be faster than the leftpad function but slower than using the built-in padStart method.
* **Built-in padStart method**: This approach is likely the fastest since it leverages the optimized implementation provided by the JavaScript engine.

**Pros and cons of each approach**

1. **Leftpad function (leftpad1)**:
	* Pros: Simple to implement, can be useful for specific use cases where padding from the beginning is required.
	* Cons: Inefficient, may cause performance issues due to repeated string concatenation or creation of temporary strings.
2. **String repeat function (leftpad2)**:
	* Pros: May offer better performance than the leftpad function by avoiding repeated string concatenation.
	* Cons: Can be slower than using the built-in padStart method if the padding length is large, and may cause issues with character encoding or overflow.
3. **Built-in padStart method**:
	* Pros: Optimized for performance, reliable, and efficient, making it a good default choice for string padding.
	* Cons: May not be suitable for specific use cases where custom behavior or string manipulation is required.

**Other considerations**

The benchmark also considers the impact of:

* **Character encoding**: The chosen approach may affect how characters are padded or handled, potentially causing issues with text encoding or representation.
* **Overflow**: If the padding length exceeds the available memory or buffer size, the chosen approach might fail or produce unexpected results.
* **Platform differences**: Different browsers or environments might optimize string manipulation differently, affecting performance and behavior.

**Alternatives**

If you want to use a custom implementation for string padding, you could consider using:

1. `Array.prototype.fill()` or `String.prototype.fill()`: These methods can be used to pad strings with a specified character.
2. `Buffer` API: If working with binary data, the Buffer API provides efficient ways to pad bytes with specific values.

However, keep in mind that these alternatives may not offer the same level of performance and reliability as using the built-in `padStart()` method or custom optimizations like the leftpad function (leftpad1).

Related benchmarks:

Testing leftpad just for lulz (version: 0)

Comparing performance of: Old npm leftpad vs string repeat vs Built-in method

Created: 2 years ago by: Registered User

Jump to the latest result

Old npm leftpad

string repeat

Built-in method

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):