Most of the above is no use to you then.
I’ll bow out ,your mind is made up.
I use Data-On-Demand ListBox from MacTechnologies.com. created by Kem Tekinay. I have listboxes that display up to 30,000 rows instantly. I can sort by column by pressing the header and it redisplays instantly. I do not use threading with these lists.
This is done via a relational database and I realize the OP is loading from an array. Not sure if Data-on-demand can do that, but it should be easy enough to create a RAM based SQL table and load from that.
It’s not free and it took me a while to get the hang of using it (likely because I’m a hobbyist and can’t devote my life to this), but I’ve not had any problems.
lhttp://www.mactechnologies.com/index.php?page=downloads
Thank you everyone for your input, especially regarding how data on demand works, and why threads are slower with each UpdateUI happening in a timer. This clarifies a lot for me.
Good ideas about UI design and other data display techniques as well. As it is now, I will require the user to do some filtering first, so the listbox is only loading a few thousand rows at most, rather than everything. This should resolve the performance issues. I agree that a listbox with 500,000 rows is pointless to the user. As it is only there as a starting point for them to then filter down to the results they need, I will simply prompt the user to make this filter query first, and then load the relevant rows.
Mostly I was just flummoxed as to why this even worked so well in 32 bit, and is now completely unusable in 64 bit with threaded tasks. The fact that its driven by a timer now answers that question.
Thanks again to everyone who provided feedback. Much appreciated.
By the way, I’ve seen this for years, and just wanted to say in my testing, making the listbox invisible first does not improve performance in any noticeable way. Instead, it creates a jarring “visual glitch” to the user where the list disappears completely and then blinks back later.
Maybe this does help for some, but in many years and many multiple tests, I’ve never found making the listbox invisible before populating it to be of any benefit. I find it interesting that this is so often suggested on these forums.
FWIW, loading about 20-60K rows with 5 cols from a dictionary into a listbox is significantly faster for me if I disable .ScrollBarVertical prior to loading.
That is interesting. I will play around with that, thank you for the suggestion.
interesting
quickly whipped up an app that loaded 100,000 rows into a single column listbox with and without the scrollbar vertical enabled
microseconds
scroll bar vertical debug built
true 1776849 1675246
false 1133390 1028455
[quote=446584:@Norman Palardy]interesting
quickly whipped up an app that loaded 100,000 rows into a single column listbox with and without the scrollbar vertical enabled
[code]
microseconds
scroll bar vertical debug built
true 1776849 1675246
false 1133390 1028455
[/code][/quote]
Very interesting indeed. Good to know, thanks!
redid this to be more “correct”
average of 10 runs each loading 100,000 rows into a one column listbox
performed on macOS 10.14.6 all on the same laptop - 2012 rMBP w/ 2.7 Ghz I7 w 16Gb RAM
app compiled with default aggressiveness
microseconds
visible scroll bar vertical debug built
true true 2755081.387 1755543.294
true false 1642546.874 1080265.231
false true 907177.873 620031.292
false false 273254.566 168029.087
however, on windows you may need to incorporate calls to the Win32 api to freeze updates and unfreeze them as not doing so when making the list invisible & visible may result in flickering
EDIT : posted link to the project
Really good to know, thanks Norman.
Did run the test on my Windows 10 desktop with AMD Ryzen 7 1700X 3.8 ghz in Xojo a63and i get strange results when scrollbar vertical is true:
microseconds
visible scroll bar vertical debug built
true true 5655531,090 5433353,560
true false 729509,490 698596,750
false true 4436855,260 4365760,990
false false 170919,260 139164,560
It seems that the program doesn’t even start automatically, you have to click in the main window and after that you see the moving circle indicating that the program works.
Before i saw that the result of the test in the first row in built mode was 12425078.650, more than 2 times the value when clicked in the window.
To me this means that there is something seriously wrong in the windows version of the scrollbar implementation of the listbox.
What a mess makes this forum software, if i edit the message everything looks fine and after saving all spaces are reduced to a single one.
How can i prevent that?
Post it encapsulated in CODE Tags 
Example:
visible scroll bar vertical debug built
true true 5655531,090 5433353,560
true false 729509,490 698596,750
false true 4436855,260 4365760,990
false false 170919,260 139164,560
Thanks Sascha, i hope i can remember that for a next time.
turns out that link is bad and now I cant edit the post 
so here is the link