Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WinUI 3 Performance: A Leap Forward

github.com

Post reply on HN
Print view View original

81–90 of 143 posts

Re: WinUI 3 Performance: A Leap Forward

#81

Post by antiloper »

pjmlp wrote: post #79
antiloper wrote: post #75

Earlier quoted context omitted.

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.

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.

Can I see the profiler data that shows AddRef/Release being a performance bottleneck?

Re: WinUI 3 Performance: A Leap Forward

#82

Post by nxobject »

antiloper wrote: post #75
pjmlp wrote: post #73

Earlier quoted context omitted.

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…

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.

For that matter, AppKit was first released on a NeXT with a 25 MHz 68030 and 8MB of RAM.

Re: WinUI 3 Performance: A Leap Forward

#84

Post by drysart »

ChrisRR wrote: post #83

I'm stilll shocked that we're reinventining the wheel of things that were solved 20+ years ago, like UIs, and somehow making them massively more resource intensive

It's tempting to look at it that way; but that's being over-reductive. UIs of today are not the UIs of 20 years ago. Users expect much more from today's UIs, and UI toolkits necessarily get more complex as a result in order to deliver on those increased expectations.

And if you don't agree, this is Windows we're talking about. Nothing's stopping you from creating your application with Win32 except for the fact that it's going to look and feel like an application from 20+ years ago.

Re: WinUI 3 Performance: A Leap Forward

#85

Post by Yoric »

pjmlp wrote: post #73
kristianp wrote: post #58

> benchmarks (like this one: 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 do…

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…

> WinRT is the Windows team final response to Longhorn, but lets do it with COM and C++, which started in Vista.

Not sure what you mean, I was using COM and C++ for Windows development in the late 90s.

> So there is no elision, it is AddRef/Release all over the place.

...and constructing an object is an insanely complex (and expensive) operation.

Re: WinUI 3 Performance: A Leap Forward

#87

Post by pndy »

boromi wrote: post #69
tiffanyh wrote: post #30

I run macOS every day, and while I find Apple Silicon shockingly fast - I'm surprised at how shockingly slow Finder seems to be. This might be off topic, but wish Apple would focused on Finder performance (app loading, window refresh, etc) like this blog post by Microsoft. And in case you're curious, my disk is only using 250GB in use (50GB for Apps, 150GB for System Data, 50GB for macOS)

Explorer.exe is far slower. It was one of the reasons I switched to macos after being a hardcore microsoft fan for many years. explorer would be so slow with fodlers that has a large number of files it would darastically impede my workflow. Macos is far superior IMO than windows when it comes to daily use efficiency.

I decided to tryout W11 in vm to see how it works in comparison to W10 and damn, current Explorer not only is slow but feels like taped together with at least 3 different UIs.

Re: WinUI 3 Performance: A Leap Forward

#88

Post by pjmlp »

Yoric wrote: post #85
pjmlp wrote: post #73

Earlier quoted context omitted.

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…

> WinRT is the Windows team final response to Longhorn, but lets do it with COM and C++, which started in Vista. Not sure what you mean, I was using COM and C++ for Windows development in the late 90s. > So there is no elision, it is AddRef/Release all over the place. ...and constructing an object is an insanely complex (and expensive) operation.

Of course you were it predates all the way back to OLE in Windows 3.x, but not the extent it is pervasive in modern Windows past Vista.

After Longhorn's failure, Windows team vouched to replicate all the .NET based ideas for Longhorn, as COM in Vista, followed by the Hilo code sample in Windows 7, how modern Windows applications should look like.

https://learn.microsoft.com/en-us/previous-versions/msdn10/f...

Best quote from Hilo, to show how Windows team sees .NET,

> So overall C++ is a good choice for writing Windows 7-based applications. It has the correct balance of the raw power and flexibility of C, and the sophisticated language features of C#. C++ as a compiled language produces executable code that is as close to the Windows API as is possible and, indeed, the C++ compiler optimizer will make the code as efficient as possible. The C++ compiler has many of options to allow the developer to choose the best optimization, and Microsoft’s C++ compiler is one the best ways to produce small, fast code. WinRT was the next step, coming back to the ideas that predated .NET as the COM evolution, before Microsoft got distracted with J++ and the project pivoted.

https://arstechnica.com/features/2012/10/windows-8-and-winrt...

https://web.archive.org/web/20190111203733/https://blogs.msd...

Re: WinUI 3 Performance: A Leap Forward

#89

Post by pjmlp »

antiloper wrote: post #81
pjmlp wrote: post #79

Earlier quoted context omitted.

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.

Can I see the profiler data that shows AddRef/Release being a performance bottleneck?

Yes, learn to use one and point it to a C++ Github project full of shared pointers.

Re: WinUI 3 Performance: A Leap Forward

#90

Post by IndrekR »

smallstepforman wrote: post #56
throwaway613746 wrote: post #34

Earlier quoted context omitted.

macos itself is sluggish af I booted up an OLD imac stuck on 10.something, with an - I can't remember which gen - i5 and only 8gb of ram and I was blown away by how much it FLIES on that ancient hardware - even compared to my M1 Max Mac Studio Apple Silicon is great. Everything else sucks.

Well, they could have had BeOS instead of NeXTStep.

Jobs would have been lost with that move...
Post reply on HN