Saw something new in a customer performance profile, a *ton* of time spent in the LSP DidChangeHandler. It's uncertain, but my guess is the customer did a Find/Replace that ended up doing a huge number of edits within the current file. The way the Roslyn didChange handler currently works, it takes each of those edits and creates a new SourceText. (This is something I'm going to pursue in a separate PR).

Each of those new source texts ends up calling into ChangedText.GetLinesCore, and subsequently the LineInfo indexer, during the didChangeHandler. This is the method that ends up showing in the profile (23.5 seconds of CPU time in the trace, which was 40% of CPU time in the VS process)

The change here is to allow SourceText a way to create TextLine's with a known extent, avoiding the overhead involved with calling the LineInfo indexer.