Hands-On with Visual Studio 2022 17.3 Preview 2 on Arm

Posted on June 15, 2022 by Paul Thurrott in Dev, Windows 11 with 21 Comments

I upgraded a Windows on ARM PC to the latest Insider build and then installed Visual Studio 2022 17.3 Preview 2 on Arm. It was a stark reminder of the challenges this platform still faces.

Like most of you, I don’t use Windows on Arm regularly. But unlike most of you, I can if I want: I keep a Windows on Arm PC around specifically for testing purposes. And while the basics haven’t changed at all—I’m very much hoping that that next-generation NUVIA-based Qualcomm chipset family pays off—it’s still part of the job. I need to keep up on this stuff.

And to be fair to Microsoft, which is complicit if not mostly responsible for the failings of this niche Windows platform, there’s been a lot of movement on the Arm front in recent months. We’re starting to see more and more core Windows 11 experiences, from the Windows Store to Media Player to Notepad, upgraded to native Arm codebases. And Microsoft is really turning the corner for developers: in addition to the Project Volterra developer hardware, the software giant announced at Build 2022 that it was porting .NET/.NET Framework, Visual C++, and Visual Studio to Arm. Incredible.

And now it’s available in its first preview build. Naturally, I needed to try it.

The Windows on Arm PC I have is an HP EliteBook Folio. It’s a gorgeous 2-in-1 with a unique (well, semi-unique now that Surface Laptop Studio is a thing) form factor and possibly the single best keyboard I’ve ever used on a laptop. Unfortunately, it’s also running Windows 11 on Arm, which means that everything else about this PC is terrible. Despite its high-end (for Arm) specs—a Qualcomm Snapdragon 8cx Gen 2 processor and 16 GB of RAM—this thing runs slower than a Pentium Gold-based Surface Go. It’s terrible.

And I was reminded of that when I decided to install the Visual Studio preview. First, I had to—or, at least, did—upgrade to the latest Windows Insider Preview build, since this machine is on the preview (and in the Dev channel, which was stupid in retrospect). That process took all afternoon for reasons I can’t explain: after an hour or more, it rebooted, so I assumed it was installing the build. But when the desktop came back up, no build had been installed. So I had to start the process all over again.

We were out last night, so when we got home, I woke up the Folio and pressed the Restart button so the build could fully install. That happened overnight, of course, so when I got up in the morning, I made coffee and set about downloading and installing the Visual Studio Preview.

Here again, I have a hard time explaining why this took so long. But to put this in perspective, I routinely install the latest Visual Studio version on whatever Intel/AMD-based laptops I use, and the three-ish workloads I use require roughly 17 GB of downloading and the whole process takes about 30 minutes.

With the Folio, it took one hour and 17 minutes to download and install just 1.6 GB of stuff. This preview version of the product only supports three workloads—ASP.NET and web development, .NET desktop development, and Desktop development with C++—but because each is just a subset of what you get on x86/x64, the size is less than 1/10th as big. I did install all three.

With that monotony out of the way, I launched Visual Studio, which looks and appears to work just like its x64-based sibling. That makes sense.

But what I was really interested in was whether this thing could handle one of my .NETpad projects. I updated two of them, the Windows Forms version and the Windows Presentation Foundation (WPF) version, earlier this year. And since both should be covered by that .NET desktop development workload, they should theoretically work just fine on Arm.

I went with the WPF version since it’s my favorite. I was able to clone my GitHub repository normally, though I waited for all the background tasks to finish since Arm PCs are so slow to begin with.

And then, suspiciously and with some trepidation, I clicked the Build button.

Everything happened slowly: It is Arm, after all. But incredibly, the application started up and ran normally. .NETpad lives on Arm!

This is actually pretty impressive. I figured there would be something, some WPF component or whatever, that would trip this thing up. But it just worked.

In-app (Visual Studio) performance, predictably, is pretty slow. But to be fair, some actions are slow in the x64 versions of this product too. For example, the default view for XAML files splits between a XAML preview and XAML code, and that’s so slow normally that I turn off the preview pane. But on Arm, it was laughably slow. I think it took about 40 seconds to come up.

But whatever. That this works at all—that Microsoft went to this effort now, when Windows on Arm is barely on life support—is impressive. And it will certainly make it easier for developers to test their apps on Arm. The trick, of course, will be convincing anyone to do so.

So we’ll see what happens. But this is a neat little step forward. Shaky and slow to be sure. But a step forward.

Tagged with , ,

Join the discussion!

BECOME A THURROTT MEMBER:

Don't have a login but want to join the conversation? Become a Thurrott Premium or Basic User to participate

Register
Comments (21)

21 responses to “Hands-On with Visual Studio 2022 17.3 Preview 2 on Arm”

  1. trparky

    An hour and 17 minutes to download 1.6 GBs of data? Hmm... must not have really fast Internet. My fiber connection would download it in less than ten minutes.

    • rob_segal

      Paul wrote download and install. Visual Studio Installer downloads the components its needs and installs them in the same process. An hour and 17 minutes for Visual Studio Installer to install 1.6 GB of selected components is pretty bad. That is really, really slow.

      • Paul Thurrott

        It is unexplainably bad, yes.

        • rob_segal

          I expected it to be slower, but this slow? I'm really surprised. A 50% increase in performance is not nearly enough for Qualcomm's chips. It may need something closer to a 500% increase in performance and that's not going to happen.

      • spiderman2

        From the screenshot I see a download speed of 400KB/s ... Maybe you should be 100% sure before say something like "An hour and 17 minutes for Visual Studio Installer to install 1.6 GB of selected components is pretty bad. That is really, really slow."

        • Paul Thurrott

          You're commingling download speed with install speed there. Visual Studio does both at the same time.


          But I did take several shots during this time period, and the last one in which the download was still ongoing occurred at 8:06 am, which was 36 minutes after the download started. It was 91 percent done downloading (and 50 percent done installing). The download finished at 8:12 am, or 1 hour and 12 minutes after it started; the install was 81 percent complete then.


          So the download was over twice as slow as usual, as was the total install time, as noted.

        • rob_segal

          I've never seen the Visual Studio Installer take that long to install these few components. 1.6 GB is not a lot of stuff for Visual Studio. When I was on Windows, I selected a lot more than that and it installed much quicker than this. I've done it dozens of times. Those three workloads are not that big relative to how much bigger the rest of Visual Studio is. No data science, no emulators, no test components, no gaming stuff, no IOT, none of that stuff. Just basic ASP.NET and desktop development, which brings with it a selected number of Windows SDK's. This is really, really slow.

    • Paul Thurrott

      Please note that I wrote that I routinely download and install 17 GB of data via the x64 version of Visual Studio in about 30 minutes. It's not the Internet connection, it's the PC.

  2. geoff

    My daughter has a Surface Pro X.

    16G of RAM, which was the most available as an option.


    It's very thin and very light, which were priorities #1 and #2, because she's a student and carries it all day. It also has a pen that is housed in the keyboard. A great touch screen and no fan noise, because there are no fans.


    She runs Office365, Spotify, Edge and Chrome, and that's about it. A few drawing tools as well.


    I give it a try from time to time, and I admit it's excellent. It's fantastic.


    My wife's PC is old and slow and due for replacement. She asked me to get one for her as well.


    In the last 30 years, my wife has NEVER spoken about PCs. So this one must be good.

    • christianwilson

      I agree. Surface Pro X is a great PC for the right workloads.


      I used it as my secondary/mobile machine for work (I'm a sys engineer) and it mostly got the job done but I had to deal with too many incompatibilities. I have since switched to a Surface Pro 8. It's a little heavier but more appropriate for my needs.


      For personal use, Surface Pro X would be totally fine for me.

      • geoff

        I'm still waiting for something incompatible to strike. In more than a year of solid use, it hasn't yet.

        (My solution is easy: "Just use this other laptop for a while and give me a chance to fix it." There are a few laptops in this house, so no problem.)


        Zoom and Teams and YouTube and WhatsApp Desktop all get a run. Also a few ebook (textbook) apps that seem to just be web browser wrappers. No problems yet.


        I thought printer drivers would be the first noticeable issue, but so far every printer has 'just worked'. All are cheap consumer grade Inkjets or small lasers. All at least 5 years old. That's a very small sample size (perhaps 4 at most), but it is a random selection.


        I suspect games will be the main issue for most people.

        As a parent of a student, a failure of the PC to run 'heavy' games (and hence get distracted for hours and hours) would actually be a bonus! But in truth, I have no idea if games run or not.

        None of us are anything more than (very, VERY) casual gamers, so we haven't hit that wall yet.


        It seems *installing* Visual Studio absolutely is a real hurdle - but is *running* Visual Studio also a problem?

        (That is - is the installer doing some funky half-baked emulation/translation which slows everything down to crawl, but the app itself runs as native code and is OK?)

        We don't need to run Visual Studio (on any of our PCs) anyway, but I guess one day things might change.

  3. cliffordsf

    Maybe this preview hasn't been optimized and the next release will be?

  4. dftf

    Looking at the spec for the machine, it is odd for it to be that slow, yes: 8-core SD 8cx Gen2; 16GB LPDDR4 4266Mhz RAM; 512GB PCIe NVMe SSD. So with 16GB of RAM, the machine would be unlikely to be paging, and there is no slow eMMC type SSD in-use here.


    My main theory would be that, while the Visual Studio app itself is now ARM-native, the installer is probably still AMD64, and therefore will run slower (especially when decompressing the installer archive-files) due to the translation.


    Beyond-that, the only two other things I could think of are (1) if the "Core Isolation" feature is enabled in the Windows Security app, maybe it doesn't work-well on ARM CPUs; or (2) is the CPU running at full-speed, or do you have any power-settings set to reduce-performance, or perhaps force only the use of the efficiency-cores?

  5. wunderbar

    I wonder if one of the real issues with Windows on ARM has to do with a bad storage controller on that chipset. Almost like the computers running Snapdragon SoC's just can't read/write to the SSD fast enough. Not sure if it's bad hardware or ineffeicent code somewhere, but it really feels like the biggest bottleneck in these systems has to do with stroage performance.


    I have a Galaxy Book Go with the 7c Gen 2 and I find it no better or worse day to day than a comparable Core i3 laptop, assuming you stick to ARM apps. But any time I need to install updates, it takes forever, and when I look at performacnce while doing those updates it isn't like the CPU is running at 100%, or the SSD is pinned to 100% either. For some reason the read/write to the SSD is just... slow. That's the big issue there.


    And no, I do not recommend anyone buy Windows on ARM. having the caveat of "it runs fine if you stick to these 5 apps" is a non starter for most people.

    • dftf

      According to what I can find, Paul's device has a Toshiba XG6 KXG60ZNV512G brand SSD fitted (M.2 2280 form-factor; PCIe 3.0, 4-lanes; NVMe 1.3a) and uses the TC58NCP090GSD controller.


      Website thessdreview.com gave it a "Gold Seal" award and said it was "one of the fastest SSDs they'd come-across at the time, short of the Intel Optane series. Tom's Hardware also gave it a fairly-glowing review, stating that during a 50GB mixed read-write load test, it averaged "339MB/sec"; similarly, storagereview.com praised most parts of the drives performance, but said that "random-write 4K performance was poor, peaking at 94,516 IOPS" (which an online-calculator tells me equates to 387MB/sec). Now, sure, for a drive that can do around 3GB/sec when only doing reading or writing, 339-387MB/sec is bad in-comparison... but it still not so-bad it was cause Paul's long-delays.


      So... I'm not sure what-else could be?

      • wright_is

        That is the controller on the NVMe module. That still needs to talk to the integrated Qualcomm NVMe I/O controller.


        I think @Wunderbar is talking about the Qualcomm controller side of the equation, not the Toshiba one, or the ARM drivers for the controllers.

  6. DBSync

    Paul, why not try it on your M1 Mac?

    • curtisspendlove

      Yeah.


      Love or hate Apple; but it’s *really* embarrassing for the rest of the industry to have better performance on an Mx chip “emulating” most of this software way faster than the native non-Apple ARM chips can run it natively.


      My MacBook M1 Pro runs all of this stuff (including ARM Linux) faster than any of it runs on any of the native ARM chips I have (granted that is mostly the Raspberry Pi).


      And with the hardware-assisted Linux x86 emulation Apple just released, it’s going to get even better.

    • donawalt

      @DBSync yes agree! I have Parallels running on an M1 Max 16" MacBook Pro, and Windows 11 is very fast - I have not a single complaint.

  7. thalter

    Works great on my Mac Studio running Windows 11 Pro total download and install time was probably less than a minute. Everything is super fast - this is one of the most responsive versions of Visual Studio I've ever used, quite frankly. I still suspect that a significant percentage of WOA installs are on Apple hardware - only MS telemetry knows for sure, though.

Leave a Reply