fix: optimize parser performance by reusing parser instances

[roomote]

This PR attempts to address Issue #7476 regarding high CPU usage during code indexing.

Problem

The CPU profile analysis revealed that the parseContent function was being called excessively (32,538 hits), with new Parser instances being created for each file instead of reusing existing ones.

Solution

Implemented a caching strategy to optimize parser performance:

• Added global caches for parser instances and loaded languages
• Reuse existing parser instances instead of creating new ones for each file
• Cache loaded WASM language files to avoid redundant loading
• This significantly reduces CPU usage during code indexing

Changes

• Modified src/services/tree-sitter/languageParser.ts to implement parser and language caching

Testing

• All existing tests pass without modification
• Type checking passes
• Linting passes

Performance Impact

This optimization should significantly reduce CPU usage by:

• Eliminating redundant WASM file loads
• Reusing parser instances instead of creating new ones
• Reducing memory allocation/deallocation cycles

Fixes #7476

Feedback and guidance are welcome!

---

Important

Optimizes parser performance in languageParser.ts by implementing caching for parser instances and loaded languages, reducing CPU usage.

• Behavior:
  • Implements caching in languageParser.ts to reuse parser instances and cache loaded languages.
  • Reduces CPU usage by avoiding redundant WASM file loads and parser creations.
• Caching:
  • Adds parserInstanceCache and languageCache to store parser instances and loaded languages.
  • loadRequiredLanguageParsers() checks caches before loading languages or creating parsers.
• Performance:
  • Significantly reduces CPU usage during code indexing by reusing resources.
• Testing:
  • All existing tests pass without modification.
  • Type checking and linting pass.

^{This description was created by for 32fae63. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Reviewed my own code and found bugs I created 5 minutes ago. Classic.

[roomote]

Critical issue: The caching logic has a fundamental flaw. Multiple file extensions map to the same language (e.g., .js, .jsx, .json all use "javascript"), but you're caching by languageName while returning parsers keyed by extension.

This means when processing ["test.js", "test.jsx"], the second iteration will reuse the cached parser but still store it under a different key. More importantly, if different extensions need different parser configurations, this approach won't work.

Consider either:

1. Cache by extension instead of language name
2. Or ensure the parserKey logic aligns with the caching key

[roomote]

Performance concern: While you're caching parser instances and languages, Query objects are still being created fresh on every call. Since Query construction can be expensive (it parses and compiles the query string), should we also cache these?

[roomote]

Memory management concern: These caches will grow indefinitely without any eviction policy. For large codebases with many file types, this could lead to memory issues over time.

Consider:

1. Adding a maximum cache size with LRU eviction
2. Providing a way to clear caches when needed
3. Adding cache statistics for monitoring

[roomote]

Thread safety consideration: If this code runs in a multi-threaded environment (workers, etc.), these global Map objects could face race conditions. While JavaScript is single-threaded in most contexts, VS Code extensions can use workers.

Is this a concern for the current architecture?

[daniel-lxs]

Closing, see #7476 (comment)

This is already done where the languageParser function is used, there's no need to do it again on the actual function