[sdk] investigate if using a set is quicker for awaiting resources in logs/span processors

[pichlermarc]

Idle perf thought (not really related to this PR): The common case will be all these logRecord.resource things being the same resource object. I wonder if using a Set to reduce the number of resource objects to Promise.all() on would be faster.

Originally posted by @trentm in #6356 (comment)

This issue is considered done when:

• performance impact has been investigated
• if using a set is quicker, performance improvement has been implemented

[ravitheja4531-cell]

I investigated this and here's what I found:

Two hot spots

1. BatchLogRecordProcessorBase.ts (lines 22–37) — waitForResources() calls waitForAsyncAttributes() once per log record in the batch. Since all LogRecordImpl objects from the same LoggerProvider share a single Resource reference (via _sharedState.resource), a batch of 512 log records calls waitForAsyncAttributes() 512 times on the exact same object — creating 512 redundant Promise<void> allocations and microtask chains.

2. BatchSpanProcessorBase.ts (lines 192–202) — Identical pattern. All SpanImpl objects from a Tracer share the same Resource reference (via this._resource in Tracer), so a batch of 512 spans triggers 512 redundant calls.

Proposed fix — Set deduplication

Using a Set<Resource> to collect unique resource references before calling waitForAsyncAttributes() collapses 512 calls to 1 in the common single-provider case:

const uniqueResources = new Set<Resource>();
for (let i = 0, len = logRecords.length; i < len; i++) {
  const res = logRecords[i].resource;
  if (res.asyncAttributesPending && res.waitForAsyncAttributes) {
    uniqueResources.add(res);
  }
}
if (uniqueResources.size > 0) {
  await Promise.all(
    Array.from(uniqueResources, r => r.waitForAsyncAttributes!())
  );
}

Set insertion is O(1) by identity (pointer comparison), so the overhead is negligible.

Deeper observation — ResourceImpl.waitForAsyncAttributes() doesn't memoize

In ResourceImpl.ts, waitForAsyncAttributes() is an async method that doesn't cache its in-flight promise. If 512 concurrent callers land while asyncAttributesPending is still true, all 512 independently await each attribute promise and write back the same results. A complementary fix would be to memoize the promise in ResourceImpl so any concurrent callers share a single execution — this would protect all processors (including SimpleSpanProcessor and SimpleLogRecordProcessor) without needing per-call-site dedup.

Benchmark gap

• sdk-trace-base benchmarks exist but don't exercise the flush/export path with async resources
• sdk-logs has no benchmarks at all

Happy to implement the Set dedup fix for both batch processors (and optionally the ResourceImpl memoization) if this approach looks good. Would appreciate feedback before proceeding.