resolve-taghelper performance issue
IlyaKhD opened this issue · comments
Each time a .cshtml file is reopened in VisualStuido 2015 a new process created:
Microsoft.Dnx.ApplicationHost Microsoft.AspNet.Tooling.Razor resolve-taghelpers --protocol 1 Microsoft.AspNet.Mvc.Razor <OtherTagHelperAssemblies>
While it is being executed the Intellisense doesn't work (this brings some annoying inconvenience), and for some reason this process takes much more time for documented TagHelpers.
Check PerfTest console app in this branch.
I've created two fake TagHelper NuGet packs (hosted on MyGet) containing 200 TagHelpers (each has 20 properties). The only difference is that properties in the second pack have summary.
You can run the following commands:
> dnx resolve-taghelpers
> dnx resolve-taghelpers-withsummary
On my environment it takes 3 sec and 21 sec accordingly.
The thing is hidden in aspnet/Razor.
Documentation file is read each time a DocumentationDescriptor is built, though while resolving TagHelpers this file could be loaded only once for each assembly.
The issue is illustrated here: IlyaKhD/Razor@db7d1a5
This is not a fix, of course, but caching brings me from 21 sec to 5sec, which is 4 times better.
@IlyaKhD thanks for the investigation! I've looked at your branch and profiled it and it turns out the System.Xml.Linq.XDocument calls we're performing are slowing the system down considerably.
Caching is definitely the correct fix for this in Razor! Would you mind filing an issue on aspnet/Razor/issues for this? We'll definitely fix this for RC2.
I've filed a new issue: aspnet/Razor#630
Btw, what I mean by 'this is not a fix' is that there several classes which could be responsible for caching an assembly documentation file, so I'm not quite sure this fix is an appropriate one.
Thanks @IlyaKhD! Awesome bug/follow up. In the end there's just not enough high volume TagHelper uses out there quite yet so what you reported is super valuable 😄
Closing since you created a Razor issue.