Is there any reason to sort named member symbols in structured type properties?

[auvred]

I noticed that getNamedMembers -> sortSymbols takes 2.5-3% of total tsgo --noEmit execution time.

I wonder if there any particular reason to sort members here? For type-checking purposes it doesn't matter whether properties are sorted or not.

Without this sorting, some tests obviously fail because they rely on error messages where the order of properties matters. So maybe property sorting should only be done when formatting error messages/suggestions?

[jakebailey]

It's possible that it only matters for errors, but my impression from reading the code is that we may have places where order matters, e.g. for things like union reduction on mappings over properties.

Perhaps we could make the sort lazy.

[jakebailey]

Though I will note that the slow thing in the trace is the map access in compareNodes, which can only be the source file ordering check. I think we're actually just missing a fast path for when the source files are the same.

[jakebailey]

Can you try #760?

[auvred]

On microsoft/vscode it went from 2.6% (flamegraph in issue body) to 2.2%:

[jakebailey]

Interesting, given the original trace was about the same length of time, but GetSourceFileOfNode was not a big factor there. Definitely, better, though.