It would probably be more efficient if you treated the rain more like a particle effect. I'm assuming this implementation would be for a 2D platformer game, this being SFGHQ and all. Here's what I suggest:
Maintain a version of each collision mask that is calculated in relation to the screen, not the level. Ideally, this would be true for all objects and the background. Optimize by only calculating these derived masks for objects that are onscreen. Also, they really only need to be rectangular masks in most cases.
Draw/emit the raindrops at the top of the screen (sY = 0). Calculate their physics separate from the main game objects. The physics for the drops would be in relation to the screen, not in relation to the game. This way, the drops only have to be accounted for from sY = 0 to sY = sHeight.
Now, you can use the derived screen-relative collision masks to create a single aggregated mask that the rain responds to. Poll objects to see what's onscreen (Maybe even maintain a vector or list that contains references to all onscreen objects at all times), then combine all those collision masks into a single polygon to create the new mask.
Now you effectively have a separate physics environment running in relation to the screen, and a collision mask positioned relative to the screen. At this point, you can tell your rain particles to disappear, splash or whatever once they collide with the mask.
If you want the rain to appear more linked with what's going on in the game physics, you can have the rain change its velocity as an inverse function of the player's. If the player is running to the right, drift the rain to the left a little. If the player is falling down quickly, have the rain fall slower.
How bout them apples?