I'm not too experienced on this topic so I'm wondering if waiting 5 & 6 cycles to get RMS is quick enough for my application.
Since you have not told us what you application is, we can't tell you either. ;-)
Ideally I wanted to get RMS in the first 1/2/3 cycles, but I don't think it is possible as the frequencies don't line up. The closest alignment I find is with the 100 ms period for a fixed sampling frequency approach.
Sure, 100 ms is the smallest common multiple of the two periods (20 ms and 16.66 ms), so there is no shorter sampling window which is compatible with both frequencies. What you could do is a sliding RMS calculation which lets you update your putput or display more frequently:
Always do your RMS calculations over a window of 100 ms length, and retain those 100 sample values. Every X ms (where X is between 1 and 99), forget the oldest X samples, append X new samples, and calculate the RMS over the new set of 100 samples.
That way, you can get display which updates more frequently than 10 times per second. But it will always show an RMS value which represents the average over the past 100 ms, hence will respond to fast changes of the input with a gradual change of the output, which lags behind a bit.
In practice, it's best to chose an X which is a divider of 100, say 10 or 20, and pre-calculate the sum and the sum of squares for each chunk of X samples. Then you don't have to do the whole 100 calculations every time, and don't have to actually store the 100 values. Just store the averages for, say, 5 sub-windows of 20 samples each, and manage these in the "forget the oldest, append a new one" scheme described above.