I thought we agreed that the cumulative effect is very noticeable?
Indeed and they are much slower than they should be. Opening the leaf menu should be practically instant even from an HDD… but it isn’t. The application menu is also slow… lots of things are slower than they should be.
FWIW, the leaf menu and the applications menu in it are instantly popping up for me.
Granted, it’s a 2.3ghz i7MQ (low power) +SSD. Populating the About window is visible, but only takes approx. less than 1/10s.
I’m sure there are many things yet to be optimized. A detailed profiling of the biggest offenders would be more interesting than subjective estimations. (<- I mean that in a most unoffending way 
)
If you find some slowdowns are noticeable, you can open bugreports about them. Then we can investigate.
There is little point in blindly benchmarking everything, I think.
However, comparing against BeOS isn’t exactly fair. We have antialiased fonts, GUI layout, and localization, and that’s just looking at the first level of what’s going on. Of course it’s going to be somewhat slower. In the case of localization, there is room for optimization, for example because we compute a hash for each string, and this can end up taking a noticeable time when there is a lot of text. We are also trying to load catalog string from various places (packaged/non-packaged, as resources in the executable or as standalone file, standalone file in data/catalogs or next to the application, and using various catalog formats that are loaded from add-ons (themselves loaded from various directories). This adds up to quite a lot of system calls and disk access before anything gets done.
The application menu is also snappy for me, both on bare metal and in VMs here (though in VirtualBox it lags somewhat; but VirtualBox has atrocious performance in general so I don’t think this is Haiku’s fault.)
It was noticable in both VirtualBox and VMware from the very first days of Haiku. There is already a ticket for that though https://dev.haiku-os.org/ticket/4335
BeOS doesn’t have this lag in VMs of course.
VirtualBox’s atrocious performance kind of is Haiku’s fault… other OSes don’t have this problem but that’s a separate issue.
syscall batching might help reduce any overhead with more syscalls?
Also note, that the way BeOS drew menu accelerants (a split second after a menu was shown) subjectively made menus appear faster. But since accelerants were disabled in Haiku long time ago we can’t recreate this effect.
our menus are implemented as separate windows, which means spawning a thread, and setting up a separate app_server link everytime one is started. You can even manage to add regular BViews into a BMenu with some tricks (I know - and actually I wrote - at least one app that uses this to have a slider in a popup menu).
So, they are at least as slow as any other window because of this. But having them reuse the parent window app_server link would require a lot of special casing, because in Haiku the app_server link is tied to the drawing state, and our menus need a separate drawing state from the window they come from.
Would it be possible to do as much of this ahead of time as possible… so top level menus are always open just hidden, the rest of the menus are spawned and populated as soon as the main menu is shown, and only shown once moused over or clicked?
That would probably require more memory to implement but it could be faster.
Or is that not a concept that can be supported?
I am sure people will groan over this idea: but what about maintaining a menu window pool in the interface kit in some way. I suppose it may have to be per application, but ideally it could be shared, otherwise it would waste some memory. But that may not play well with each application having a link to the app_server.
No, it’s VirtualBox’s fault. IPIs (Inter-Processor Interrupts) take a few nanoseconds on QEMU/KVM, VMware, and real hardware; on VirtualBox they take up to multiple milliseconds, even in the 100s range with multiple cores. It’s absolutely ridiculous and not our fault at all. Our scheduler uses these for efficient thread rescheduling, so that’s why Haiku is slow in VirtualBox.