Performance Optimization of the qs Library: A 5× Speedup Case Study

This article documents a practical performance‑optimization case study of the popular JavaScript URL‑query‑string library qs . A Tencent engineer discovered that processing a 30 MB Chinese text payload caused a Node.js process to crash due to heap‑out‑of‑memory (OOM) errors.

Problem discovery : The crash was reproducible with test data. Debugging showed that the OOM originated from the internal encode function, which traverses the input string character‑by‑character and repeatedly concatenates strings, leading to massive temporary allocations.

Root‑cause analysis : JavaScript strings are immutable; each concatenation creates a new string, causing high memory pressure. The encode loop iterates over more than 30 × 1024 × 1024 characters, exceeding three hundred million iterations.

Initial mitigation attempts :

Storing intermediate characters in an array and joining at the end reduced execution time slightly (≈5 s) but increased memory usage to >1.9 GB (negative optimisation).

Splitting the input into smaller chunks and processing each chunk separately also proved ineffective because the final array‑to‑string conversion remained a memory bottleneck.

Optimised solution : The engineer introduced a chunked‑processing strategy:

Divide the input string into fixed‑size segments (1024 characters proved optimal).

For each segment, encode characters into a temporary array, then immediately join the array into a string and append it to the final result, allowing the temporary array to be released.

Key code snippet:

var limit = 1024;
var out = '';
for (var i = 0; i < string.length; i += limit) {
  var segment = string.slice(i, i + limit);
  var arr = [];
  for (var j = 0; j < segment.length; j++) {
    var c = segment.charCodeAt(j);
    arr.push(c);
  }
  out += arr.join('');
}

Benchmark results:

Original qs (v6.12.0) – 30 MB test: 7855 ms, 2.5 GB heap.

Optimised version (v6.12.1) – 30 MB test: 2090 ms, 0.48 GB heap.

This represents roughly a 5× speed improvement and a 5× reduction in memory consumption.

Open‑source contribution : The engineer submitted a pull request, which was reviewed, approved, and merged within 34 hours. The change was released as a new version of qs , becoming the only performance‑optimisation update in the library’s history.

Conclusion : Even mature, widely‑used libraries can contain hidden performance bottlenecks. Systematic profiling, chunked processing, and careful management of temporary data structures can yield substantial gains. The case also demonstrates the value of contributing back to open‑source projects, benefiting both the community and the contributor’s own projects.