In addition, the new version adds and modifies a number of APIs we rely on to interact with the IDE. Those who have upgraded 32-bit code to 64-bit code before know that, even in well-architected code, it takes some work even just to review code to ensure it is correct. Since Visual Assist (VA or VAX) runs as a plugin, in-process, we needed to build a 64-bit version of our plugin DLL. Visual Studio (VS) 2022’s main change-and it’s a significant one-is that it will become a 64-bit process. Personally, I get rather tired of slapping the escape key to cancel IntelliSense multiple times just so I can write out a dotted expression.Visual Assist 2021.3 running inside Visual Studio 2022 Preview 3 Visual Studio Preview If I am undoing the suggestions I didn't want, yet it insisted on placing, it is counterproductive. It is great for telling you about what exists, but falls on its face when you're trying to write something new. It is an active hindrance for writing/designing APIs. I think I can boil down my gripes with this: IntelliSense is wonderful for consuming APIs. Like Pretzold, I have a love hate relationship with IntelliSense. I've tried the 2022 preview (I have not yet tried RTM), and there are excruciating pauses in the UI for seconds to create a new file in an empty project! But, there are great new features in there, too. And speed of the IDE itself has been dodgy at times, even for brand new projects. And one of the most frustrating things for the longest time was that if you needed a specific C++ compiler major version, you were stuck using the specific VS version that shipped with the compiler (unless you were willing to ditch projects and go with makefiles). With each release, it does somethings better, or new, but others worse, sometimes cripplingly so. In my experience, it's never been a straight forward conclusion of version X is better than the one before. The codebase I contribute to is so much more pleasant to work in with VS 2022. But I won't be looking a gift horse in the mouth. My personal belief is that 64-bit could have been reasonably accomplished many years ago, and it would have been the right call to do it then. * If you commit to something ambitious like going 64-bit only, engineers can meet the challenge and produce something very good * You really don't know what the impact of something is going to be until you actually do it * Marshaling data between processes still requires use of the UI thread in VS in various scenarios, due to a wildly complicated threading model that people mess up all the time * A 64-bit devenv.exe process gives the GC more "room to work with" and do more background GCs rather than foreground GCs, which will pause the UI far less The solution it suggested was for memory-intensive components to move out of process, which is actually what many of them did in VS 2017 and VS 2019.īut the problem with this article is that it was entirely speculation. 64-bit is also objectively slower than 32-bit in terms of CPU time to execute stuff. If you make this 64-bit, pointers double in size and you could observe even more memory usage. Specifically, the articles laid the blame for things like memory usage (which when high enough, causes a foreground GC in the devenv.exe process that freezes your UI), on language services that get all too happy to allocate tons of memory. Yeah, this was from a series of articles that were a great example of managing to be right about all kinds of things but still be wrong in the end. >but among the stated reasons to stick to 32-bits not so long ago, and even one of the main, there was: performance. I know folks on the inside are working to improve this dramatically (they know roughly how to do it), but it's a long road ahead. It's so easy for any little component to mess things up, hang the UI, and make someone have a terrible experience. VS still relies on a very very old COM-based UI model with one of the most convoluted and complex threading models to manage it that I've ever seen. VS 2022 is a fantastic new release (64-bit solves so many perf and user-perceived reliability issues), but there is so much more to go. What the person you're replying to has experienced is very real - I saw it come up again and again and again in reports - and I hope that things improve for them with subsequent releases. People should not be surprised by the behavior of their tools, and they should not be frustrated by random freezes or crashes all of the time. So I worked on VS tooling for a few years and I'm proud of what me and my peers achieved, but I don't think this is the right perspective. If you are having to fight with VS, then you may not be using it for one of its main use cases.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |