perf: improve isomorphic decode performance

[anonrig]

No description provided.

[KhafraDev]

Is there still a performance improvement?

Considering that a majority of inputs are likely less than 65k characters, would it be possible to use the initial implementation of String.fromCharCode(...input) only if the input is smaller than that? That way the small inputs have a fast path, and larger ones use a fallback (slower) method.

[anonrig]

You are right @KhafraDev. I’ll update my pull request.

[ronag]

LGTM as a refactor... but I'm sceptical this is faster in any meaningful way

[mcollina]

I don't think this could make things faster.

[anonrig]

I've added the optimization recommended by @KhafraDev. Since the benchmark uses a payload greater than 65k in length, there seems to be a performance effect. I don't know if it's worth it.

[ronag]

Does this provide any significant perf improvement? I'm sceptical... Seems more like added complexity without benefit.

[anonrig]

Does this provide any significant perf improvement? I'm sceptical... Seems more like added complexity without benefit.

I can revert to the previous change (without arguments length path), or just close this.

[ronag]

Does this provide any significant perf improvement? I'm sceptical... Seems more like added complexity without benefit.

I can revert to the previous change (without arguments length path), or just close this.

I'm fine with the reduce version.

[KhafraDev]

If the original 3.8x faster benchmark is correct, it seems like an easy addition for better data url fetch performance without any side effects.

[anonrig]

If the original 3.8x faster benchmark is correct, it seems like an easy addition for better data url fetch performance without any side effects.

In either scenario, this pull request is faster then previous implementation

╔═══════════════════╤═════════╤═══════════════════╤═══════════╗
║ Slower tests      │ Samples │            Result │ Tolerance ║
╟───────────────────┼─────────┼───────────────────┼───────────╢
║ slow-length-66000 │   10000 │    2390.91 op/sec │  ± 0.61 % ║
║ fast-length-66000 │   10000 │    2841.13 op/sec │  ± 0.72 % ║
║ slow-length-300   │   50000 │  588204.84 op/sec │  ± 0.94 % ║
╟───────────────────┼─────────┼───────────────────┼───────────╢
║ Fastest test      │ Samples │            Result │ Tolerance ║
╟───────────────────┼─────────┼───────────────────┼───────────╢
║ fast-length-300   │  100000 │ 2301211.51 op/sec │  ± 1.04 % ║
╚═══════════════════╧═════════╧═══════════════════╧═══════════╝

Implementation

import cronometro from 'cronometro'

const MAXIMUM_ARGUMENT_LENGTH = 65535

function slow(input) {
  let output = ''

  for (let i = 0; i < input.length; i++) {
    output += String.fromCharCode(input[i])
  }

  return output
}

function fast(input) {
  if (input.length < MAXIMUM_ARGUMENT_LENGTH) {
    return String.fromCharCode(...input)
  }

  return input.reduce((previous, current) => previous + String.fromCharCode(current), '')
}

const value = new Array(300).fill(4)
const valueLarge = new Array(66000).fill(4)

cronometro({
  'slow-length-300'() {
    return slow(value)
  },
  'fast-length-300'() {
    return fast(value)
  },
  'slow-length-66000'() {
    return slow(valueLarge)
  },
  'fast-length-66000'() {
    return fast(valueLarge)
  }
}, { iterations: 100000 })

[ronag]

Yes, interestingly there is a significant perf diff with String.fromCharCode(...input). Confirmed with a separate benchmark also.