very poooor performance when debugger attached

[springy76]

I'm using NJSonSchema indirectly by using NSwag.

If there is no debugger (=VS2017 15.6) attached then generating swagger.json takes 2-3 seconds (still way too slow, Swashbuckle takes a fraction of a second for the very same app).

If the debugger is attached then the same thing takes 4-5 MINUTES !!

It took my some time to notice that the event log of Diagnostic Tools was flooded with Threading: Task "<unknown Id>" Started. messages, some thousand per second (since timestamp was only changing on second fraction every 10-20 messages). Historical debugging always shows FileExistsAsync in stack trace, which always calls Task.Factory.StartNew (IMHO a very bad thing).

Since the only caller of FileExistsAsync is this position I would suggest putting an empty document into the cache instead of the value null so it only happens once per file.

[RicoSuter]

I know there is still a lot of potential to improve performance - right now some things are not really optimized for speed. I think most of the time is used for $ref resolution (JsonPathUtilities) because it has to scan the whole graph (even multiple times). But yes, FileExistsAsync and all these file APIs should not use Task.Run but directly call the sync methods...

Can you create a PR?

[RicoSuter]

Probably we should remove all these Task.Factory.StartNew in DynamicApis

[springy76]

I'm currently just using NuGet packages but from the source here it's very obvious that Dictionary<string, XDocument> Cache does not handle Exists = false results.

[RicoSuter]

I don't see why File.Exists isn't cached, see https://github.com/RSuter/NJsonSchema/blob/1a251418bc25445acd8076194c33ed6ab7c01f53/src/NJsonSchema/Infrastructure/XmlDocumentationExtensions.cs#L209

Update Correct now? https://github.com/RSuter/NJsonSchema/blob/master/src/NJsonSchema/Infrastructure/XmlDocumentationExtensions.cs#L208

[RicoSuter]

The most expensive part is the $ref resolution: