We added a smoke test and a benchmark around the child_vaccination_VOL_tool_v12 form to see whether we could identify systematic issues. We were able to find some small performance improvements to make without fundamentally changing how repeats are implemented but we remain convinced that the behavior you experienced was due to activity outside of Collect.
Collect v1.28 has just been released and includes slight performance enhancements and code simplification related to the form. You've probably already tried the betas but as a reminder, we encourage everyone with repeats or complex form logic to carefully try out v1.28.
One thing I want to flag as definitely expensive to do is having calculations that act across instances of repeats. For example, count and sum calculations can really slow down a form. If you can avoid those, then you at least shouldn't have any significant slowing down as new repeat instances are added.
I think that ideally the answer to these nested scenarios would be a dedicated way of representing related entities as the threads about longitudinal data collection describe. This is a ways off but I do hope it's where we'll be going.
Yes, definitely. I think your experiment sounds good to get a ballpark idea of how things go. I'd start with a really improbably big scenario first to see if it's even worth doing more experimentation (like 1000 dwellings). I'd also urge you to add a new dwelling instance as part of your experimental protocol to trigger form re-computation. If you don't have any calculations across repeat instances (sum, count), that should be virtually instantaneous.