Textfield Input Performance Degredation With Long Select Lists

[saladd-bu]

Hello,

We're getting closer to moving Dialog in as our primary computer enrollment tool. However, while testing, we're seeing some performance degradation with Textfields on forms with Select lists that contain numerous values. Overall, performance decreases when entering text as Dialog complexity increases (e.g., adding Infobox, additional fields, etc.). However, we've seen a more direct correlation between Textfield performance and the length of our Selects.

This issue has generally appeared to be more prominent on older Intel hardware. For example, a 2015 15" MacBook Pro exhibits the issue with smaller lists than a 2020 M1 MacBook Air. With the 2015 model, performance drops fairly rapidly after exceeding around 40 combined select list choices. With the M1 Air, it became noticeable in the hundreds. Unfortunately, for our workflow, we're looking at presenting two Select lists, each with approximately 300 values, and a third Select with seven values. Acceptable on new hardware, quite frustrating on old machines.

Performance of the Select list in these moments is fine. It really is only when typing text into a Textfield that this becomes noticeable. Activity Monitor also shows a CPU spike while inputting text.

Example dialog where the issue was tangibly noticeable on the 2015 MacBook Pro:

/usr/local/bin/dialog --textfield "Text 1" \
--selecttitle "Select 1" \
--selectvalues "a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,x,y,z,aa,ab,ac" \
--selectdefault "a" \
--selecttitle "Select 2" \
--selectvalues "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35" \
--selectdefault "1" \
--infobox "#### Serial Number:\n C02RXXXXYYYY"

Screen capture of how CPU utilization responds:
https://user-images.githubusercontent.com/105297926/219781950-4668102c-fc6e-4d30-bcfa-8c7959a74d38.mp4

[bartreardon]

I'm not sure how much I can affect this issue last it seems to be inherent in SwiftUI. In the background we're passing around a lot of data to keep the view updated and whenever there is a change, SwiftUI will re-draw the window. Textfields in particular can be chatty as they update the app state after every keypress vs a dropdown which only updates on select. With select lists of 300 or more there's going to be a lot of app state change and subsequent re-drawing of the display which will have a significant impact, particularly on old hardware. I'd argue that 300 entries in a dropdown list is quite excessive in any case and I'd look to see if there was another way to solve what you want to do.

[saladd-bu]

That's about what we expected. We ended up moving it to a second dialog in the process that contains just these two dropdowns. The only way we could think to shorten the lists would be to filter based on the computer name provided in the form. But, since that would require a dialog submission anyways and hefty logic for our scale, we took the easy route.

It'll do until we get to our dream future state some day!

[dan-snelson]

@saladd-bu: While I haven't been following your specific use-case, robjschroeder has a snippet of code which may prove interesting:

https://techitout.xyz/2023/04/12/setup-your-mac-zoom-room-edition/

[saladd-bu]

@dan-snelson That's actually a great find. I suppose for us, we could do something similar based on wired network IPs, but it would be a hefty endeavor. My colleague has been working on a naming convention to building/department mapping approach, but it's quite hefty.

Future state for us we're thinking will be using our internal web tool portal for our technicians. They can go in there and preset the registration data for both Macs and PCs, then the device will pull that via API during deployment. With our device management policies, would be our best chance to get to zero-touch and eliminate these data entry at runtime steps.

Bart, I suppose if there's no good way of limiting the view updates when typing, I'm okay considering this closed unless there's something you have in mind. I did still see some slowdowns the other day with just one select of around 8 choices on the form, but it wasn't that concerning.

[bartreardon]

I might leave it open for now - I have ideas about having something that could allow you to have department->building->room type layouts in the same dialog. The idea would be you select "department" first and then that populates the next dropdown with a filtered list of buildings and that in turn could affect a filtered list of rooms. Keeping this open will remind me that I have something to do (if that type of thing would solve your issue)

[saladd-bu]

Oh, that would actually be fantastic. I could see that being useful for a lot of scenarios, not just this one. Great idea!

[dan-snelson]

Dynamic Drop-down Menus take me back to my Web Dev days, Bart.

[bartreardon]

I still think of ajax as a new technology

[bartreardon]

this should be fixed in 2.3.1 - let me know if there's still an issue

[bartreardon]

closing as fixed - if there's still issues I can re-open