Noticeable delay opening a markdown file (source)

[bpasero]

I am noticing a delay when I click on a markdown file until it opens. I think this is a regression from the new markdown extension but I am not sure what piece could cause it.

//cc @jrieken if you have clues

[jrieken]

It's starting a process that encapsulated the rendering

[jrieken]

A dupe of #7066

[bpasero]

@jrieken I see this when opening the markdown file in source, not preview. I am aware of the delay when previewing.

[jrieken]

hm... is the grammar we are using?

[jrieken]

Holy moly - the parsing/loading the grammar is slow. Tho it only happens once/the first time. @aeschli @alexandrudima ideas how to seep that up? Is it better to use JSON instead of PLIST?

CPU-20160627T140746.cpuprofile.zip

[alexdima]

This sounds like an opportunity for a great new plist-to-json node module that is streamlined to only handle plist. I'd love to write that :)

[jrieken]

Maybe we can use the native DOMParser for this (https://developer.mozilla.org/en-US/docs/Web/API/DOMParser)

[alexdima]

@jrieken vscode-textmate is a node module and should in theory not use browser API. We can, as always make it injectable with a different plist parser.

[alexdima]

I am on the path of writing a plist parser.

before:

after:

[jrieken]

Tho, I'd still like to see how it compares to the DOMParser ;-)

[alexdima]

before.CPU-20160630T185643.zip
after.CPU-20160630T185657.zip

before:

after:

[alexdima]

To the verifier: please check that you can get the previous (slow) parser when setting the "hidden" preference editor.useExperimentalParser = false. I've added this to have a fallback in case my 10x faster parser has a bug, so we can switch back to the SAX based parser based on a setting. I will remove the setting after our confidence grows, by default the setting is on (use faster parser by default).

[bpasero]

Works great in terms of performance 👍