paths.normalize(): perf regression

[bpasero]

Running the following test with profiling enabled shows that recent changes to paths.ts cause a major performance regression:

• open the monaco folder
• expand some folders
• click refresh 10 times

Before:

After:

profiles.zip

[jrieken]

impossible ;-)

[jrieken]

Seems like it gets into the deopt-state cos it was optimised to many times...

[bpasero]

Sorry I have to reopen this because I notice that the UI is freezing when I do a gulp watch from the command line while having Code open. I profiled the explorer refresh again as well as starting a profile before running gulp watch and measuring after this is done (vscode sourcecode workspace):

Explorer refresh new

Explorer refresh old

Compile all new

Compile all old

profiles.zip

[jrieken]

@bpasero I don't understand how that is related to gulp watch? This is outside of VS Code and triggered by file events?

[jrieken]

might be an optimisation I removed to do nothing in case of an already normal string...

[bpasero]

@jrieken the gulp watch causes file events to be triggered in relatively short time frame that probably spam our listeners in the window that all do normalization.

I think spamming file events is a sensitive topic for the workbench because many listeners are in the UI thread and most of them do path/uri magic. We could try to pull out more of that to the file watcher process but nevertheless it is a good test case for measuring performance in path/uri land.

[jrieken]

@bpasero Please check this again if you don't mind. I took the shortcut to figure out first if a path is normal - which in case of gulp watch all paths are. The implementation doesn't use a regex anymore, is more correct than before, esp wrt double slashes. The sad part is that using charCodeAt isn't much faster than a regex...

[jrieken]

Ok - hold on. RegEx for the win! Using /\/\.\.?\/|\/\.\.?$|^\.\.?\/|\/\/+|\\/ for checking posix paths is magnitudes after (23ms vs 120ms)

[bpasero]

@jrieken yeap, back to good, thanks!