Gentlemen, before we start another "alternative plugin language" discussion, let's step back and have a look at what we have.
The plugin presented by STR_Warrior is a raw one, a developer version, and it is in need of polishing before we can call it a proper plugin. The performance problems aren't caused by slow plugin language, they're caused by using somewhat wrong idioms. These are the main reasons why things tend to get slow, and no alternative language is gonna solve a badly chosen algorithm.
Let's analyze this plugin:
On every world tick, for each tornado, it basically calls RipGround and PullEntities (we're concentrating on the hot path here). The RipGround function iterates over the entire tornado's ground coverage and selects a few blocks to rip out. It basically is a big loop that says: Do this 441 times: calculate a random number, in 1/250 of cases, dig the block. So basically this uses a double for loop with 441 calls to random in order to rip out 2 - 3 blocks. We're smarter than that, we can do better:
NumBlocksToRip = 2 + random(2)
for i = 1, NumBlocksToRip do
local BlockX = m_Pos.x + random(21) - 10
local BlockZ = m_Pos.z + random(21) - 10
-- Rip out block at {BlockX, Height, BlockZ}
end
This alone should improve the performance hugely.
Then the entities. They don't need constant guidance. They can be pulled every other tick, or even every 4 ticks. Again, savings on the order of 75 % work. Even the ground ripping can be done in every Nth tick, possibly ripping out more blocks if needed.
I believe these changes alone should make this plugin viable.