Pool collators in LS

[jakebailey]

Collators are not safe for concurrent use, so we create them fresh. But, pprof shows that collate.New is 15% of the time spent in the fourslash tests.

Stick them in a sync.Pool per language.

[Copilot]

Pull Request Overview

This PR optimizes the language server's completion functionality by pooling collators to avoid the performance overhead of repeatedly creating new collator instances. Profiling showed that collate.New was consuming 15% of execution time in fourslash tests.

• Implements a per-language collator pool using sync.Pool and collections.SyncMap
• Replaces direct collate.New() calls with pooled collator retrieval and return
• Adds helper functions getCollator and putCollator to manage the pool lifecycle

Comments suppressed due to low confidence (1)

[Copilot]

The putCollator function assumes the pool exists in the cache, but there's no guarantee. If the pool was somehow evicted or never created, this will panic. Add a nil check or use LoadOrStore pattern similar to getCollator.

Suggested change

	pool, _ := collatorCache.Load(tag)
	pool, _ := collatorCache.LoadOrStore(tag, &sync.Pool{
	New: func() any {
	return collate.New(tag)
	},
	})

[jakebailey]

Suggested code is wrong because it'll just waste loads and loads of allocs. If I wanted to solve this, I'd just return a done func from get.

[DanielRosenwasser]

Why is this a LoadOrStore instead of just a Store?

[jakebailey]

Otherwise two callers would update totally different maps