fix: prevent O(n²) memory allocation in content lookup map generation

[amankumarpandeyin]

Changes

Fixes #14893

• Replaced O(n²) object spread pattern with direct mutation in generateLookupMap
• For each content/data entry, the code was creating new objects via {...lookupMap[collection]?.entries, [key]: value}
• With 10,000+ entries, this caused ~50 million string copies (n × n/2)
• Now uses nullish coalescing (??=) and direct property assignment - O(n) complexity

Before:

lookupMap[collection] = {
  type: 'content',
  entries: {
    ...lookupMap[collection]?.entries, // ← Creates new object each time
    [slug]: rootRelativePath(root, filePath),
  },
};

After

lookupMap[collection] ??= { type: 'content', entries: {} };
lookupMap[collection].entries[slug] = rootRelativePath(root, filePath);

Testing
All 1326 existing tests pass (3 unrelated failures: clipboard + network flakes)
All content-related tests pass: Content Collections, references, render(), Intellisense

Docs
No docs changes needed - this is an internal performance optimization with no API changes.

[changeset-bot]

🦋 Changeset detected

Latest commit: b90634a

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[ematipico]

I'm going to create a preview release so we can test if this change will provide benefits

[pkg-pr-new]

npm i https://pkg.pr.new/astro@14973

npm i https://pkg.pr.new/@astrojs/svelte@14973

npm i https://pkg.pr.new/@astrojs/markdown-remark@14973

commit: b90634a

[codspeed-hq]

CodSpeed Performance Report

Merging #14973 will not alter performance

_{Comparing amankumarpandeyin:fix/lookup-map-oom (b90634a) with main (ef53716)¹}

Summary

✅ 6 untouched

Footnotes

1. No successful run was found on main (4264a36) during the generation of this report, so ef53716 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[matthewp]

Wonderful @amankumarpandeyin thank you! Do you have any anecdotal data, did this improve your build performance for example?

[amankumarpandeyin]

Wonderful @amankumarpandeyin thank you! Do you have any anecdotal data, did this improve your build performance for example?

@matthewp thanks! i was experiencing OOM errors with large content collections (10k+ entries)... after this change builds complete without memory issues... the fix eliminates the quadratic object copying that was causing 50M string copies for that scale