8 ms·

> benchmarks (like this one: https://github.com/Noemata/XamlBenchmark https://github.com/Noemata/XamlBenchmark), WinUI 3 is currently measurably slower than bot

> benchmarks (like this one: https://github.com/Noemata/XamlBenchmark https://github.com/Noemata/XamlBenchmark), WinUI 3 is currently measurably slower than both WPF and UWP. WPF is 20+ years old and even it is not native!!!. Older stuff is generally faster because it had to be built in a more resource poor time. Maybe the WinUI devs should be forced to work on systems with the Minimum System Requirements. Heck, maybe all Microsoft development should be done like that, so that some focus on performance is there from the start, instead of as an afterthought.

vitorgrs 5mo ago
If I recall right, Windows 8 and Windows Phone 7/8 during the 2010's were all developed on low end devices. Both had huge issues UX wise, specially desktop, but performance and stability was never a issue. Developers should always test their system on the minimum system requirement that they allow the system to be installed... I remember I complained about WinUI performance years ago, and they told me at the time that "performance" was not the focus...
- adithyassekhar 5mo ago
  I am sure this was posted so many times before but someone should reverse engineer the windows 8 era windows phones. Those were ridiculously smooth compared to android and ios with just 512mb of ram.
  - Topfi 5mo ago
    WP was incredibly smooth and they were willing to reinvent UX from first principles in ways that'll to this day make me reach for Sailfish OS if I didn't need physical buttons, but I must bring up the desktop version of Windows from that day. I'll never forget the Asus Netbook proudly boasting about its 1024MB of memory via a colorful sticker that'd be considered excessively large on a 17.3" workstation, somehow running Gimp with multiple layers on Windows 8 alongside a few Chrome tabs without a care in the world. UX of 8 and 8.1 was awful, but it was optimized and stable in ways that made me hopeful for what MSFT would deliver in the future. 1gig of memory, a spinning hard drive and a single low powered x86 core were enough to get some image editing for a then school course done with some wiki pages in the background. I'd hardly believe it, had I not lived it. 10 and 11 have been regressions in my book.
    - markus_zhang 5mo ago
      I never used 8 because I hate the UI. But I used 7 for a long time. I recall that 7 was blazingly fast on a 2GB notebook back in the early 2010x. But then that was already way beyond its minimum system requirement.
    - gucci-on-fleek 5mo ago
      > UX of 8 and 8.1 was awful The UX of Windows 8 was amazing on tablets, to the point where it's still my favourite touchscreen UI. The keyboard+mouse UX wasn't very good though, which is all that >99% of users ever used. > 1gig of memory, a spinning hard drive and a single low powered x86 core were enough to get some image editing for a then school course done with some wiki pages in the background. I'd hardly believe it, had I not lived it. 10 and 11 have been regressions in my book. I had a similar experience with the earlier releases of Windows 10 also [0]. I'm not really sure when Windows's performance got worse, but it was definitely some time after that. [0]: https://news.ycombinator.com/item?id=45743066 https://news.ycombinator.com/item?id=45743066
      - adithyassekhar 5mo ago
        It’s after the 2019 release, they started optimising for ssds.
        noahbp 5mo ago
        I’d argue they started doing that a bit earlier. My hard drive from 2011 made using Windows a miserable experience any time the search indexing or windows defender scans kicked on, no later than 2016-2017.
        kasabali 5mo ago
        That isn't "optimizing for ssds" that's simply irresponsible product development.
  - GoblinSlayer 5mo ago
    I think android apps bundle pretty heavy batteries, so it's like Electron, but in java, windows can make it faster by just pushing the GUI into the system as it always did.
  - pjmlp 5mo ago
    The secret was .NET Native and C++/CX. Contrary to Windows Phones, Android was still mostly JIT compiling, with Dalvik. Windows Phone 8, used technology from Singularity, .NET Native apps were compiled on the cloud and what was downloaded was MDIL (Machine Dependent IL), on device only linking was performed. Starting with Windows 10, everything was done on cloud and you got a binary targeted to device. Android had to go through AOT compiler in version 5, 6, reintroduction of JIT with AOT on idle on 7, staring of PGO data across devices on 8, until it got into a similar kind of performance. And to this day, NDK sucks compared with Windows Phone 8 C++/CX experience.
    - vitorgrs 5mo ago
      Windows 8 Inbox apps a lot of them where WinJS actually. But on Windows 8 even web tech was fine (speed-wise). And WP 8.0 < didn't offer AOT for .NET apps. AoT only came as experimental on WP 8.1 with WinRT apps if I recall right. And on W10 and W10 Mobile, it comes as default for all UWP .NET apps.
      - pjmlp 5mo ago
        I failed to mention WinJS, because hardly anyone used it, hence why it was dropped on UWP, with the WinRT API surface reboot on Windows 10. Windows 8 had definitely MDIL support, with the Bartok linker from Singularity. Thankfully the information hasn't yet fully disappeared from Internet. https://stackoverflow.com/questions/11199234/compiling-windows-phone-8-app-in-cloud https://stackoverflow.com/questions/11199234/compiling-windo... https://www.zdnet.com/article/microsoft-details-its-strategy-for-compiling-windows-phone-apps-in-the-cloud/ https://www.zdnet.com/article/microsoft-details-its-strategy...
        vitorgrs 5mo ago
        .NET Native was experimental in WP 8.1 and W8. On 10, it becomes mandatory and you couldn't even publish a JIT .NET app to Store. WP 8.0 didn't even had WinRT, only Silverlight apps, and all JIT. If you wanted native in 8.0, had to go with C++. About Desktop, C++ was rarely used. Most apps were either .NET C# (JIT) or WinJS. JIT WinRT .NET was super slow, WinJS apps were even faster, which is why many apps were all WinJS, including inbox Windows apps, like the MSN apps.
pjmlp 5mo ago
It is quite easy to know why. WinRT is the Windows team final response to Longhorn, but lets do it with COM and C++, which started in Vista. This is why all major new APIs since Vista are COM based. So you get an UI framework with reference counting all over the place, and application identity, which is a kind of sandboxing, for the capabilities like in mobile OSes or macOS. On the UWP subsystem, you get .NET Native and C++/CX, whose runtimes are WinRT aware and can elide those RC calls. Whereas using WinRT on Win32, means regular .NET and C++, via interop frameworks CsWinRT and C++/WinRT, plain libraries. So there is no elision, it is AddRef/Release all over the place.
- antiloper 5mo ago
  I don't believe it. Reference counting is a virtual function call + an integer operation. It doesn't happen that often either because objects in UI frameworks are very long lived. C++'s shared_ptr, Rust's Rc, and Swift, don't typically cause performance problems either.
  - pjmlp 5mo ago
    Of course they cause problems as well, you not believing it doesn't change profiler facts. I can also easily point you on CppCon, C++Now and WWDC talks, where presenters spend valuable time of their lifes speaking about matters you don't believe.
    - antiloper 5mo ago
      Can I see the profiler data that shows AddRef/Release being a performance bottleneck?
      - pjmlp 5mo ago
        Yes, learn to use one and point it to a C++ Github project full of shared pointers.
        5mo ago
ksec 5mo ago
>WinUI 3 is currently measurably slower than both WPF and UWP. WPF is 20+ years old and even it is not native!!!. It is similar everywhere, they put out figures, like Teams rewritten from Electron to using native browser or something. claims to have 50% speed up. But 50% of what? We used to have bundler on web and many vocals devs were suggesting 10 min was fast enough. Atom was fast enough, Electron was fast enough. Node.js was fast enough. It wasn't until things like Zed, ( or some other editor before that ), Bun and other Bundler showing them they were 10 - 50x slower before people realise.

vitorgrs 5mo ago

If I recall right, Windows 8 and Windows Phone 7/8 during the 2010's were all developed on low end devices. Both had huge issues UX wise, specially desktop, but performance and stability was never a issue. Developers should always test their system on the minimum system requirement that they allow the system to be installed... I remember I complained about WinUI performance years ago, and they told me at the time that "performance" was not the focus...

adithyassekhar 5mo ago
I am sure this was posted so many times before but someone should reverse engineer the windows 8 era windows phones. Those were ridiculously smooth compared to android and ios with just 512mb of ram.
- Topfi 5mo ago
  WP was incredibly smooth and they were willing to reinvent UX from first principles in ways that'll to this day make me reach for Sailfish OS if I didn't need physical buttons, but I must bring up the desktop version of Windows from that day. I'll never forget the Asus Netbook proudly boasting about its 1024MB of memory via a colorful sticker that'd be considered excessively large on a 17.3" workstation, somehow running Gimp with multiple layers on Windows 8 alongside a few Chrome tabs without a care in the world. UX of 8 and 8.1 was awful, but it was optimized and stable in ways that made me hopeful for what MSFT would deliver in the future. 1gig of memory, a spinning hard drive and a single low powered x86 core were enough to get some image editing for a then school course done with some wiki pages in the background. I'd hardly believe it, had I not lived it. 10 and 11 have been regressions in my book.
  - markus_zhang 5mo ago
    I never used 8 because I hate the UI. But I used 7 for a long time. I recall that 7 was blazingly fast on a 2GB notebook back in the early 2010x. But then that was already way beyond its minimum system requirement.
  - gucci-on-fleek 5mo ago
    > UX of 8 and 8.1 was awful The UX of Windows 8 was amazing on tablets, to the point where it's still my favourite touchscreen UI. The keyboard+mouse UX wasn't very good though, which is all that >99% of users ever used. > 1gig of memory, a spinning hard drive and a single low powered x86 core were enough to get some image editing for a then school course done with some wiki pages in the background. I'd hardly believe it, had I not lived it. 10 and 11 have been regressions in my book. I had a similar experience with the earlier releases of Windows 10 also [0]. I'm not really sure when Windows's performance got worse, but it was definitely some time after that. [0]: https://news.ycombinator.com/item?id=45743066 https://news.ycombinator.com/item?id=45743066
    - adithyassekhar 5mo ago
      It’s after the 2019 release, they started optimising for ssds.
      - noahbp 5mo ago
        I’d argue they started doing that a bit earlier. My hard drive from 2011 made using Windows a miserable experience any time the search indexing or windows defender scans kicked on, no later than 2016-2017.
      - kasabali 5mo ago
        That isn't "optimizing for ssds" that's simply irresponsible product development.
- GoblinSlayer 5mo ago
  I think android apps bundle pretty heavy batteries, so it's like Electron, but in java, windows can make it faster by just pushing the GUI into the system as it always did.
- pjmlp 5mo ago
  The secret was .NET Native and C++/CX. Contrary to Windows Phones, Android was still mostly JIT compiling, with Dalvik. Windows Phone 8, used technology from Singularity, .NET Native apps were compiled on the cloud and what was downloaded was MDIL (Machine Dependent IL), on device only linking was performed. Starting with Windows 10, everything was done on cloud and you got a binary targeted to device. Android had to go through AOT compiler in version 5, 6, reintroduction of JIT with AOT on idle on 7, staring of PGO data across devices on 8, until it got into a similar kind of performance. And to this day, NDK sucks compared with Windows Phone 8 C++/CX experience.
  - vitorgrs 5mo ago
    Windows 8 Inbox apps a lot of them where WinJS actually. But on Windows 8 even web tech was fine (speed-wise). And WP 8.0 < didn't offer AOT for .NET apps. AoT only came as experimental on WP 8.1 with WinRT apps if I recall right. And on W10 and W10 Mobile, it comes as default for all UWP .NET apps.
    - pjmlp 5mo ago
      I failed to mention WinJS, because hardly anyone used it, hence why it was dropped on UWP, with the WinRT API surface reboot on Windows 10. Windows 8 had definitely MDIL support, with the Bartok linker from Singularity. Thankfully the information hasn't yet fully disappeared from Internet. https://stackoverflow.com/questions/11199234/compiling-windows-phone-8-app-in-cloud https://stackoverflow.com/questions/11199234/compiling-windo... https://www.zdnet.com/article/microsoft-details-its-strategy-for-compiling-windows-phone-apps-in-the-cloud/ https://www.zdnet.com/article/microsoft-details-its-strategy...
      - vitorgrs 5mo ago
        .NET Native was experimental in WP 8.1 and W8. On 10, it becomes mandatory and you couldn't even publish a JIT .NET app to Store. WP 8.0 didn't even had WinRT, only Silverlight apps, and all JIT. If you wanted native in 8.0, had to go with C++. About Desktop, C++ was rarely used. Most apps were either .NET C# (JIT) or WinJS. JIT WinRT .NET was super slow, WinJS apps were even faster, which is why many apps were all WinJS, including inbox Windows apps, like the MSN apps.

pjmlp 5mo ago

It is quite easy to know why. WinRT is the Windows team final response to Longhorn, but lets do it with COM and C++, which started in Vista. This is why all major new APIs since Vista are COM based. So you get an UI framework with reference counting all over the place, and application identity, which is a kind of sandboxing, for the capabilities like in mobile OSes or macOS. On the UWP subsystem, you get .NET Native and C++/CX, whose runtimes are WinRT aware and can elide those RC calls. Whereas using WinRT on Win32, means regular .NET and C++, via interop frameworks CsWinRT and C++/WinRT, plain libraries. So there is no elision, it is AddRef/Release all over the place.

antiloper 5mo ago
I don't believe it. Reference counting is a virtual function call + an integer operation. It doesn't happen that often either because objects in UI frameworks are very long lived. C++'s shared_ptr, Rust's Rc, and Swift, don't typically cause performance problems either.
- pjmlp 5mo ago
  Of course they cause problems as well, you not believing it doesn't change profiler facts. I can also easily point you on CppCon, C++Now and WWDC talks, where presenters spend valuable time of their lifes speaking about matters you don't believe.
  - antiloper 5mo ago
    Can I see the profiler data that shows AddRef/Release being a performance bottleneck?
    - pjmlp 5mo ago
      Yes, learn to use one and point it to a C++ Github project full of shared pointers.
      - 5mo ago

ksec 5mo ago

>WinUI 3 is currently measurably slower than both WPF and UWP. WPF is 20+ years old and even it is not native!!!. It is similar everywhere, they put out figures, like Teams rewritten from Electron to using native browser or something. claims to have 50% speed up. But 50% of what? We used to have bundler on web and many vocals devs were suggesting 10 min was fast enough. Atom was fast enough, Electron was fast enough. Node.js was fast enough. It wasn't until things like Zed, ( or some other editor before that ), Bun and other Bundler showing them they were 10 - 50x slower before people realise.