Building menu stalls machine

The main user-created objects in my app require a menu having around 50K items in it. Building the menu in Xojo2021r2 takes about 6 seconds. I don’t remember it taking that long when I wrote the app using a previous version of Xojo. Maybe 2 seconds, but certainly not 6, because I would have never accepted that. It now stalls the computer every time this menu has to be created. Each object that’s created has to maintain its own version of this menu.

So I just tried making /one/ menu at launch and using menuitem.clone when the objects are created. This was /not/ faster than just building the menu, it was actually /slower/ !

Is this a known problem?

What??
A ‘normal’ menu?

I’ve had customers complain about finding 20 items in a menu.

That surely cannot be the best way to offer up 50K choices
There is a a recent post about how to handle large lists, and ‘on demand’ list boxes.
Making a 50K item menu wont be a ‘known problem’ as nobody (else) would do that.

Have I misunderstood what you are doing?

It’s not a simple list of 50K things. It’s obviously a menu with many branching submenus. By design this could of course be handled differently, but it shouldn’t have to be.

I could have posted the problem this way - am I imagining things, or is it taking more than twice as long to build menus now than in previous versions of Xojo?

Gigantic popup menus are not so rare e.g. Font menus. I do understand that the decision to use such a large menu may seem ridiculous, but there are cases where it makes for the most intuitive UI.

I’ll be redesigning things to avoid the huge menu, because I have no choice. It will mean using a dialog window instead, which is what I wanted to avoid, but oh well.

I can’t think of anything, even with a Font menus, that would contains 50000 menu items, even hierarchically. Are you sure it’s the right design?
Why not having a listbox instead?
With menu items, the user can be confused, at best. Or have you found users who can deal with that already?

1 Like

You should change this. I can’t imagine any situation/app in which it’s ok/recommended to present a 50.000 Choices Menu to the user.

I would really like to know more about your app and see for myself why this is the “best” way to do it.

Maybe it should… :wink:

Guys, the question is about the speed of menu creation, not whether my design is a good one.

I agree the huge menu not the best design, and if you read above, I already told you all that I’m reworking this using a window instead of a menu, so there’s no reason to keep harping on how bad the design is / was.

Whether there is an issue with the speed of menu creation remains unanswered. Some simple tests could obviously be done. I’ll do that later.

If I could delete the original post, I would.

1 Like

This can fairly be related.
Mac OS probably doesn’t support having so many menu items inside a menu, exactly because it’s “bad design” in the first place.
And something unsupported usually reacts badly if you try anyway.

There are other similar examples where “bad design” and “lack of support from the OS” are related (after all, the ones who make the OS are also the ones who make the User Interface Guidelines telling which are good designs).

It’s not against your design, nor you, but just to be clear about the tight relation between “supported” and “as can be designed”.

1 Like

My experience is that every year computers get faster while Operating systems/ API calls get slower, due to encapsulation ,
developing on ‘cutting edge’ machines,
and a belief that space and memory are effectively ‘infinite’

A few years ago I reported an issue with drawing bitmaps in Xojo:- following an ‘upgrade’, drawing bitmaps was 50% slower if the bitmap had to be resized in the process.
Nobody else noticed because they were only doing one or two at a time and for them the impact was milliseconds if that.
For me, drawing up to a million bitmaps in a tight loop, it was a showstopper.
No-one cared, it never got fixed, changed or improved. I was an edge case.

You are in the same situation here.
Most people have less than 200 menu items and won’t see (or even bother measuring) the impact of this change, no matter how hard it hits you personally.
Xojo wont have noticed the slowdown- it will be low priority.
I sympathise.

1 Like

Jeff, thanks for that. I think your observations are spot on, and your case sounds quite similar.

I’m also reminded of life before “Power Box”. Something as basic as file access is abominably slow today compared to the old days (say, Snow Leopard).

1 Like