If you are at ~200ms and can cash in at every 20ms saved a gain of even 5ms is welcome - provided testing first and implemeting is fast.
I had not checked that angle back then, but adding hooks to my C measuring would have been done in 15 min with results as byproducts of other tests.

Implementing a strategy and alternate build method in base class, perhaps 2 or 3 embellishments in "special" cbo - under 1H.
water under the bridge...


>I simply cannot see how would 50-60 cbo's would gain valuable milliseconds. Lets do the math again even favoring COPY TO ARRAY stats with extreme:
>
>10,000 runs:
>COPY TO ARRAY: was something like 70-80 milliseconds (not on mine HW really). Let's favor it more and say done in 50 milliseconds.
>OTHERS: Were 200-300 milliseconds on my system and 500+ milliseconds on other reports. Let's say in older days it would be 5-6 times slower and be it 3000 milliseconds (and even consider even in old HW COPY TO ARRAY runs in 50 - wow 60 times faster).
>
>In 10,000 runs the gain is 2950 milliseconds. If it were for 100 cbo, then you gained 29.5 milliseconds (in reality much less).
>
>Loading cbo with values instead would be much faster, but I don't believe someone would do that to save a few milliseconds.
>
>And if those cbo were cascading, getting data from tables with more than 10-20 rows, then SELECT ... would seriously out perform COPY TO ARRAY.
>
>In your case that shouldn't be the reason for the savings.
>
>
>>I agree a lot with your POV when coding singular lines - even more, as having a higher (on small scale) runtime for all datasets is often preferable to runtimes growing exponentially on larger datasets. Buuuut: Knowledge of such facts might be important outside tight loops
>>
>>I once had to salvage an application already in service - it was too slow and user were unhappy. Contract involved specific reaction times of the program. I reused a lot of the data structures (involving a single lookup table for most of the listbox and/or dynamic text showing, as tons of maintainance screens were part of the total package, which were seldom used, fast enough and a rewrite of those would have been impossible on agreed upon budget.
>>
>>Main app had lots of screens each with lots of controls and was overarchitected - especially as choices "upward" in control flow resulted in cascading effects on controls "lower" in structure. Over 20% of the controls were cbo, which could have their data changed by such cascade.
>>
>>Contract involved reaching specific recation times on given HW. Customer wanted to always be under 100ms for next input ready - I had reserved the option of being between 100 and 250 ms after changing 10 "slowest" controls and an arithmetic mean for lag of the slowest control cascades of 175ms at max - with options for me and customer to force an additional effort for smaller gains in perf.
>>
>>Keeping cbo's array-based I did not have to touch a lot of screen/record validation (although it worked IMO on the wrong layer....) but in salvage you cut away warts for a low percentage of original dev budget. Customer was so pleased with total perf gains he did not use any option for further gains, I opted for 1 low-hanging fruit option for more cash ;-)
>>
>>Even on todays HW 30-60 cbo arrays reselected would have given me precious ms, back then the effect probably would have been much larger. On a framework level if using arrays to feed your cbos this could be relevant - the # of listbox/cbo lines should be single digit in most cases, making it a good candidate for copy to array implemented at a fwk level, perhaps with a dev property to switćh over to SQL if result set is large for 1 or 2 controls. cbo properties were responsible to define the filter used on the lookup table - no single line to type, but perhaps a chance to reuse the filter in SQL-where or Copy To Array For.