If a proc was on hold, and like 20 players is doing the same thing would this cause lags?
Depends entirely on what that thing is. Have you got an example?
NarutoBleach wrote:
Depends entirely on what that thing is. Have you got an example? | |
No, I was just wondering if that's what could cause lag on the game.
| |
Well, overly long sleeps in say ... verbs or Move(), where players notice, can give the appearance of 'lag' because they press a button, and some time much later than they expected, the action happens.
And yeah ... spawn()ing excessively (as noted in http://www.byond.com/ forum/?post=1599489&page=2#comment10600961) can produce heavy CPU load when you've got like 20+ players doing things. But your codebase does need to be pretty messy and you must be spawn()ing a lot of stuff to get that. Normally, it's not a problem, it's usually just badly written code that produces 'lag'. | |
if there was 16 spawn procs in world.New() would that cause the server to crash? xD
For some reason I can't run my server on BYOND 506.1247. Falacy's Bleach Eternity single player crashes after logging in with BYOND v506.1247. | |
Shouldn't do, no. It seems more likely that the problem is to do with what the spawned procs are doing, than the fact they are spawned.
| |
What kind of updates were there from v504 to v506 that would cause previously working code to now crash?
| |
Mmm, threading should be off by default in that build. There were performance improvements, internally, but I doubt they would cause crashes particularly, unless the code in that DMB is extremely sketchy. What kind of crash are you seeing there?
| |
When using Dream Daemon, it crashes after starting of host. When using Dream Daemon, it crashes after loading dream daemon.
| |
Not only does the code in world.New() crashes the game, the HUD that was previously created by Falacy's team is off-screen.
| |
I won't even offer it as a rule of thumb to be honest, it's just not helpful. Spawning by convention leads to scheduler thrashing, and performance problems. Basically this game had this weird notion that spawning (because it's non-blocking for the caller) meant things completed faster, so they'd spawn() callProc() a /lot/ for little reason other than the belief that callProc() was slowing the caller a bit. Then net result is BYOND's scheduler had so many spawn()'d procedures in wait state, it wasted a lot of time picking "what needs to run next" and context switching stacks.