No, I understand that exploiter has access to everything to the client, but comparing modules to one big script, a cheater can easily mess up with the game with:
require(module).something = true
“Something” can be some client configs, such as settings, state configurations (whether the player is at menu?) etc. These client config values are hard to be protected by the server. Yes, I know that one big script can be exploited too, however from what I’ve known it’s way harder than just by a simple one-lined command.
My point above might not be valid to you, but it can’t deny the fact that I love accessing different variables in one big script without worrying whether the variable is being referenced or not. Yet you might say you can just spit into few scripts that do different jobs! (Such as one for framework, one for client datastore loader) But even if they are being spitted into 2 scripts, it’s still hard to access variables, you will never know when will you use the variable in script A while working on script B.
What I can really do to boost performance is to simplify stuff inside the big script, that’s it! So far I don’t see much a problem from using one big script. According to the console, the LuaHeap never goes up to 21 MB (I don’t know is that a valid judging factor though, at least 21 MB is reasonable? It hops between 16 to 20 most of the time.)
I admit that the problem mentioned in the OP is more or less related to the “one big script” concept, but later I found out it’s because I was doing some maths inside a stepped for ALL the players in the server (basically 60 * around 15 players = 900 calculations per second lol), I’m not sure is this the root cause of the bottleneck issue but it seems to better after I remove that part of the code.
OR it might be related to this FPS counter, I’ve moved it into another script to see whether the problem will be solved.