-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve startup perf #38
Comments
Consider MRT as a file format for the docs file as it is binary and includes an index as well. |
Hello,
2021-02-15-01-56-58.mp4 |
Thanks for the feedback, @netcorefan1.
That certainly performs quite well on my system, which is running VS 2019 Update 10 (it worked on Update 9 too). It is also a pretty powerful system. That said, I would never expect the length of time or the unresponsiveness you are reporting and suspect you may have an extension that is adversely affecting you. Maybe try disabling all 3rd party extensions, restarting VS, and trying again. Those extensions that you cannot simply disable using the Extension Manager (e.g. Resharper?) you may need to uninstall for this experiment.
It is not the same. We have plans to replace the code in dotnet/pinvoke with the code projected by CsWin32 though.
Maybe not much. If you're ok with the payload size and the extra dependencies, that's fine. You're welcome to continue using those if they suite you better.
The metadata that this projection is based on is still very new and we haven't defined all the enums yet. We expect that to improve soon.
Be aware that R# may disable many built-in C# features in order to replace them. The last I heard, removing R# does not re-enable them, which may make Microsoft's own C# lang svc look broken. You should re-enable those features by hand. |
Sorry for my delay and many thanks for your suggestions. Within a month I will have to format and it will be the perfect chance to retry again on a freshly installed VS on a fresh OS. I am sure there is something wrong on my side and I will be able to fix it. If not I will let you know.
Even after I will got it to work, I don't think that the compile time will change, but I don't care because, if remember well it's one time only compilation which need to be recompiled only if we add new entries. However, if you could find a way to optimize the subsequent compilations would be really nice.
It's very interesting the ability to not depend on third party libraries and ability to compile only what we really need instead of including several assemblies and even if they are separated, it's still a great amount of stuff (it take several minutes to open the Vanara pinvoke definitions).
Yes, since Constants is a static class it should appear when imported through using static Microsoft.Windows.Sdk.Constants; With Vanara I like to have everything available in Intellisense because I can find what I need for by searching there. Would be possible to do the same with CsWin32 ? The full refactoring is something that I always do when a project is finished and means recompiling with all unused imports removed. Would be possible with CsWin32? I think it's time for me to take in serious consideration the switch. May be at beginning I felt a bit discouraged, but once I will fix the issues on a fresh OS, I feel that I will be satisfied from the new changes! |
I don't think that is correct. The compiler may both re-invoke the source generator and re-compile the output many times while you work with your code in the IDE. And AFAIK the command-line build does not cache the output of the source generator anywhere, so it gets regenerated on every compilation too.
If you only have it generate the APIs that you require, then yes that will make for overall fewer or smaller assemblies to be loaded in memory, assuming you don't just generate
|
Having used a variety of different methods of generating C# syntax in various tools, I am a fan of building strings directly (e.g. IndentedTextWriter) rather than modeling syntax. The generation code becomes twenty times more maintainable. I'm mentioning this because it seems like it could benefit performance. A member of the Roslyn team has made the same case, build strings not syntax for source generators. |
I appreciate the tip, but I don't think that's going to happen. There are too many conditions and permutations on the emitted code to ever want to deal with strings, IMO. Having an OM allows not only for "add modifier" operations that doesn't require me to parse my own string in order to find where to insert the modifier, but it leaves open some very interesting incremental generation opportunities going forward. |
Sounds good. I do want to address this point:
I don't believe this benefit is unique to having an object model. When building a string, I do operate in a forward-only manner in a single pass. This organizes the building logic in a specific way that never involves parsing my own string. I've found the organization which this forces to be simple and maintainable. |
@AArnott what prevents the generator from actually using a zip file with docs stored in a xml file split in folders named after the win32 dll they are from and the file names being the name of each structure/enum/function they are for then use an json file ( This is because System.IO.Compression zip apis are built into the BCL and the generator already depends on System.Text.Json and it would just need to add a dependency on the XML stuff which is also part of the BCL (and |
The docs will eventually be produced in the win32metadata repo, represented in a language-agnostic way so API docs can be projected for any language that supports such a thing. |
Another option is to embed the docs into each winmd file somehow generated by the metadata. |
We embed the docs in the CsWin32 projection today. But we're going to move to another model where they ship as a separate package and organized so that eventually we can even offer API docs localized to the repo's preferred (human) language. |
MRT appears to only work on Windows, and only on .NET 5.0+. That makes .pri an unacceptable format since we need to be able to parse it on any OS. |
aren’t pri files just xml files? if so What stops you from falling back to XDocument to parse it properly since it cannot be used in |
No. .pri is a binary file format. |
In the IDE the perf is ok, but build times noticeably suffer do the the startup cost of the source generator. What can be done to speed this up?
Ideas to evaluate:
Pre-index the metadata so we don't have to build up all the collections at runtime.(not a significant perf hit)The text was updated successfully, but these errors were encountered: