Yes, the data source query blocks are very slow. I came up with a bit of a hack [Data Source Performance Workaround FOUND!]. Performance is one of the reasons I use firebase realtime. The read/write times are incredibly fast and reliable (it is just text).
When cloning, which element you clone and where it is cloned are critical and unforgiving :-(.
From my remix project (Create Horizontal Scroll (Swipe Like) Row - #27 by drted), notice that the Scroll templates (the boxes with the actual data) are cloned one after the other in the same container. But the real trick is to clone the Master Column (not the scrolling column) and place it at the next-to-last element in the screen. The solution is definitely a russian-doll kind of layout with containers in containers in containers.
To show changes in the source data, I delete the cloned elements by looping through the appropriate container. Usually I just delete all of the cloned “Master Columns” then rebuild everything from scratch. I’ve played around with updating individual labels using and x/y cooridate system to refer the appropriate containers, but it was a very brittle screen. Sometimes I will cheat a little and add a label or button with some hidden text. Then I can loop through all of the compnents in the screen until I find the hidden text, then use that as a anchor for updating adjacent components. Again, pretty high maintenance, but it does provide better performance. But for most situations delete clones and rebuild sticks to K-I-S