Introduction

For 32-bit signed integers in JavaScript, the fastest practical answer is usually to use the engine’s native sort on the right container. Custom algorithms such as radix sort can win in narrow high-volume cases, but they only make sense after benchmarking against built-in sorting on real data.

Start with the Native Sort

If your numbers are in a normal JavaScript array, always supply a numeric comparator:

1const values = [10, -2, 7, 1, 42, -8];
2values.sort((a, b) => a - b);
3
4console.log(values);

Without the comparator, Array.prototype.sort() compares elements as strings, so "100" sorts before "20". That is the right default for general strings, but it is wrong for numeric data.

Modern JavaScript engines have heavily optimized native sorting implementations. For many real applications, the fastest code is simply the built-in numeric sort and no more.

Use Int32Array When the Data Is Truly 32-Bit

If the dataset is genuinely a 32-bit signed integer sequence, storing it in Int32Array is often better than using a regular array of numbers.

1const values = new Int32Array([10, -2, 7, 1, 42, -8]);
2values.sort();
3
4console.log(Array.from(values));

Typed arrays matter because they:

• store values densely in memory,
• avoid mixed element types,
• communicate that the data is fixed-width integer data rather than generic JavaScript numbers.

That often improves both memory behavior and sorting performance.

Why Custom Algorithms Usually Lose

In theory, a comparison sort is O(n log n), while radix sort can be linear for fixed-width integers. In practice, JavaScript performance depends on more than big-O notation:

• engine optimizations for native built-ins,
• memory allocation pressure,
• cost of JavaScript loops,
• branch behavior on the actual input distribution.

That is why a hand-written radix sort often looks good on paper but still loses to native sort on moderate inputs.

When a Radix Sort Can Make Sense

If you sort very large integer buffers repeatedly and the input is always signed 32-bit data, a radix sort may outperform native sort. One common trick is to flip the sign bit so signed integers sort correctly as if they were unsigned during each counting pass.

1function radixSortInt32(input) {
2  let arr = Int32Array.from(input, value => value ^ 0x80000000);
3  let tmp = new Int32Array(arr.length);
4
5  for (let shift = 0; shift < 32; shift += 8) {
6    const counts = new Uint32Array(256);
7
8    for (let i = 0; i < arr.length; i++) {
9      counts[(arr[i] >>> shift) & 0xff]++;
10    }
11
12    for (let i = 1; i < 256; i++) {
13      counts[i] += counts[i - 1];
14    }
15
16    for (let i = arr.length - 1; i >= 0; i--) {
17      const bucket = (arr[i] >>> shift) & 0xff;
18      tmp[--counts[bucket]] = arr[i];
19    }
20
21    [arr, tmp] = [tmp, arr];
22  }
23
24  return Int32Array.from(arr, value => value ^ 0x80000000);
25}
26
27const sorted = radixSortInt32(new Int32Array([10, -2, 7, 1, 42, -8]));
28console.log(Array.from(sorted));

This works, but it is more code, more memory, and more maintenance. Only keep it if benchmarks prove it is worth the complexity.

Benchmark the Workload You Actually Have

Sorting performance changes with:

• array length,
• already-sorted versus random data,
• duplicate-heavy distributions,
• ordinary arrays versus typed arrays,
• Node.js or browser engine version.

A simple benchmark should clone the same source data for every run:

1function benchmark(label, fn) {
2  const start = performance.now();
3  fn();
4  const end = performance.now();
5  console.log(`${label}: ${(end - start).toFixed(2)} ms`);
6}
7
8const source = Int32Array.from(
9  { length: 100000 },
10  () => (Math.random() * 0xffffffff | 0) - 0x80000000
11);
12
13benchmark("typed array sort", () => {
14  const copy = new Int32Array(source);
15  copy.sort();
16});
17
18benchmark("radix sort", () => {
19  radixSortInt32(source);
20});

Always benchmark after warmup and on the engine you actually deploy. Results can change materially between Node.js versions and browser engines.

Choosing the Right Strategy

A good rule is:

• regular array plus comparator for general code,
• 'Int32Array.sort() for real fixed-width integer data,'
• custom radix sort only after profiling proves native sort is the bottleneck.

That is not a theoretical answer. It is an engineering answer. The fastest maintainable solution is usually the one that lets the JavaScript engine do the hard work.

Common Pitfalls

• Calling Array.sort() without a numeric comparator and getting lexicographic ordering.
• Writing a custom sort before testing native sort on the target runtime.
• Using typed arrays only for sorting, while paying conversion costs everywhere else.
• Assuming asymptotic complexity guarantees the best runtime in JavaScript.
• Forgetting that both native sort and custom sort usually mutate the input array.

Summary

• For most workloads, native numeric sort is the right starting point.
• 'Int32Array.sort() is often the best fit when the data is truly 32-bit integer data.'
• Radix sort can win for very large fixed-width workloads, but only after benchmarking.
• Measure on the actual JavaScript engine and dataset that matter to your application.
• Prefer the simplest solution until profiling proves you need something more specialized.