perf: remove unnecessary stack trace capture in promiseTimeout and delayCancellable

[jlucaso1]

promiseTimeout() and delayCancellable() capture stack traces via new Error().stack on every call, causing CPU overhead from source map parsing. These functions are called in hot paths (every WebSocket message, query, etc.).

Benchmark Results

Benchmark: 5000 ping/pong messages received and sent back.

CPU Profile Comparison

Function	Before	After	Improvement
serializeJSStackFrame	~1.0%	0%	Eliminated
promiseTimeout	~0.6%	0.02%	30x reduction

Memory Profile

Metric	Before	After
Source map allocations from stack capture	~2.5 MB	0 MB
serializeJSStackFrame in heap	Present	Gone

---

Proof: Boom has native .stack

Boom creates native Error instances and calls Error.captureStackTrace(). The .stack property is preserved.

From Boom API docs:

Creates a new Boom object. Decorates the error with Boom properties using boomify().

const Boom = require('@hapi/boom');
const err = new Boom.Boom('Test', { statusCode: 500 });
console.log('stack' in err);        // true
console.log(err instanceof Error);  // true

[whiskeysockets-bot]

Thanks for opening this pull request and contributing to the project!

The next step is for the maintainers to review your changes. If everything looks good, it will be approved and merged into the main branch.

In the meantime, anyone in the community is encouraged to test this pull request and provide feedback.

✅ How to confirm it works

If you’ve tested this PR, please comment below with:

Tested and working ✅

This helps us speed up the review and merge process.

📦 To test this PR locally:

# NPM
npm install @whiskeysockets/baileys@WhiskeySockets/Baileys#perf-remove-stack-trace

# Yarn (v2+)
yarn add @whiskeysockets/baileys@WhiskeySockets/Baileys#perf-remove-stack-trace

# PNPM
pnpm add @whiskeysockets/baileys@WhiskeySockets/Baileys#perf-remove-stack-trace

If you encounter any issues or have feedback, feel free to comment as well.

[rsalcara]

Hi @jlucaso1, everything good? I implemented this PR in my fork. and obtained the results below.

📊 Performance Impact
Before (without PR):
1,000 contacts to map:
├─ getLIDsForPNs: 1,000 individual queries
├─ getPNsForLIDs: did not exist
├─ Store: 2,000 queries (read + write)
├─ Stack traces: +1.6% CPU overhead
└─ Total: ~5,000ms + 2.5 MB RAM

⚠️ Total: 3,000+ DB queries

After (PR):
1,000 contacts to map:
├─ getLIDsForPNs: 1 batch query
├─ getPNsForLIDs: 1 batch query
├─ Store: 2 queries (1 read + 1 write) write)
├─ Stack traces: 0% overhead
└─ Total: ~150ms + 0 MB extra

✅ Total: 4 DB queries

🚀 Speedup: 33x faster
💾 Memory: -2.5MB
🔋 CPU: -1.6%

[jlucaso1]

@rsalcara What? This isn't to reduce database queries. It's just to reduce overhead when generating errors.
And these numbers were obtained in my benchmark:

💾 Memory: -2.5MB
🔋 CPU: -1.6%

How do you run this benchmark heuristic?

[rsalcara]

Hi @jlucaso1!
I incorrectly posted the combined results of all 3 PRs in this PR's thread,
making it seem like the database improvements came from your
stack trace optimization. They didn't — they came from the batching PRs.

Your PR #2270 correctly focuses on error generation overhead, not database queries.

Sorry for the confusion! The stack trace removal works perfectly and delivers
exactly what you described. 👍

[github-actions]

This PR is stale because it has been open for 14 days with no activity. Remove the stale label or comment or this will be closed in 14 days