Detecting Load‑Bearing Code with Execution Tracing

The hidden cost of a blind audit

Most teams start a code audit by scanning import graphs or counting lines. That tells you what could be called, not what is called in production. The result is a long list of “critical” modules that never see traffic, and a short list of dead code that silently inflates the dependency tree. When the audit ends in a report, you have spent weeks on speculation instead of fixing the real load‑bearing parts of the system.

Execution tracing as a load‑bearing detector

Execution tracing records every function entry while the application handles a real workload. By aggregating the call counts you get a concrete picture of the critical path: functions that run thousands of times are load‑bearing, those that never fire are candidates for removal or refactor.

The technique is model‑independent and repeatable. The same trace run on the same input always yields the same frequencies, because it is a pure instrumentation of the code, not a generated prediction. The data can be fed directly into a code audit, turning a vague “what might be used?” question into a factual “what is used?” answer.

Minimal harness you can drop into any repository

Below is a short Node .js harness that instruments CommonJS modules. It records call frequencies in a JSON file that can be inspected later or consumed by an audit pipeline.

// trace-harness.js
const fs = require('fs');
const path = require('path');
const counts = {};

function wrapExports(exports, modPath) {
  if (typeof exports === 'function') {
    return function traced(...args) {
      counts[modPath] = (counts[modPath] || 0) + 1;
      return exports.apply(this, args);
    };
  }
  if (typeof exports === 'object' && exports !== null) {
    for (const key of Object.keys(exports)) {
      const val = exports[key];
      if (typeof val === 'function') {
        exports[key] = function traced(...a) {
          counts[modPath + ':' + key] = (counts[modPath + ':' + key] || 0) + 1;
          return val.apply(this, a);
        };
      }
    }
  }
  return exports;
}

// Hook into require
const Module = require('module');
const originalLoad = Module._load;
Module._load = function(request, parent, isMain) {
  const filename = Module._resolveFilename(request, parent);
  const exported = originalLoad.apply(this, arguments);
  return wrapExports(exported, path.relative(process.cwd(), filename));
};

// Run the target script
const target = process.argv[2];
if (!target) {
  console.error('Usage: node trace-harness.js <script>');
  process.exit(1);
}
require(path.resolve(target));

// When the process exits, write the trace
process.on('exit', () => {
  fs.writeFileSync('trace.json', JSON.stringify(counts, null, 2));
});

Run it against your entry point with a realistic workload:

node trace-harness.js ./src/server.js < input-data.json

After the run, trace.json contains entries such as:

{
  "src/utils/math.js:add": 12457,
  "src/controllers/user.js:getUser": 342,
  "src/unused/legacy.js:oldHelper": 0
}

Modules with a count of zero are dead code; those with high counts are load‑bearing. The JSON can be fed to a static analysis tool or a custom script that flags any module whose total count falls below a configurable threshold.

Turning the trace into a code audit

1. Collect traces from a representative set of workloads (e.g. CI test run,

staging traffic, or a production snapshot).

1. Aggregate the per‑run JSON files; sum the counts per module.
2. Classify modules:

• Critical – count > threshold, part of the critical path.
• Marginal – count ≤ threshold but > 0, may be kept for future use.
• Dead – count = 0, safe candidates for removal.

The classification becomes the basis of a code audit. Because the data originates from actual execution, the audit report is actionable: you can open repair branches that delete dead modules, move critical functions into a shared library, or rewrite marginal code to improve testability.

The workflow aligns with the loop described in the pillar post /blog/closing-the-loop-from-repository-audit-to-merged-repair: trace → audit JSON → self‑contained repair branches → merged repair.

If you need to automate branch creation from inconclusive harness results, see the related post /blog/automating-repair-branch-creation-from-inconclusive-harness-results.

How SHPBL makes it repeatable

SHPBL supplies a model‑independent, repeatable pipeline for exactly this scenario. Its certification harness can execute the same trace‑harness and record a CERTIFIED verdict when the call‑frequency data matches the declared contract. The library of reusable capabilities is accessed through a single method—MCP server, HTTP API, typed TypeScript client, or offline files— so you can integrate tracing into any CI environment without additional tooling. A free repository evaluation lets you try the method on a small slice of your code before committing to the full audit. Details are on the /evaluation page.

---

Monday action: add the trace-harness.js script to a branch, run it against your staging workload, and inspect trace.json. Flag any module with zero calls and open a repair branch to delete it. The next audit will start from a concrete, load‑bearing view of your codebase.