Well listening to PlayerMoveEvent on large servers won't really cause any significant damage. The frequency of the event being called is high so limiting yourself to light code in such events would be great. F.e: Don't keep checking if a player is inside an octagon everytime PlayerMoveEvent is called. Maybe you can do a coordinate test to check whether the player moved a significant distance and only then proceed to check if point in octagon.

I think empty events are fine, but not handling the event is always better. The event calling code is highly optimized and handle it or not, there's enough code already executed in attempting to call the event. PMMP has empty packet handlers for currently unhandled packets and it doesn't cause any significant performance drop. ¯\_(ツ)_/¯

Take an example of an anticheat plugin that listens to PlayerMoveEvent on a lower priority (i.e anticheat's listener gets executed before the region listener, eg: LOW, LOWEST). In this case, my region checker listener won't execute if your anticheat plugin cancels the event.
Saved you a few code execution!

Also see my analysis in https://forums.pmmp.io/threads/reas...ng-the-myths-of-its-performance-impacts.5603/
Although that article might be slightly outdated, one thing isn't changed: It's just a few extra function calls, and as of PHP 7, the function call overhead is very small. What people usually think is that 4 or 5 function calls would have an impact on some event that involves dozens of other internal function calls.
My personal principle is, unless your optimization involves more than 1ms execution, more than 50% performance improvement or different time complexities, it is a premature optimization.
Just look at the other function calls in a single move event, then you'd see that a few extra function calls have no impact on the whole server.

Please evaluate the proportion of events that are cancelled. Do you really think preventing these calls would make a significant difference? It's very likely that a PlayerMoveEvent or a DataPacketSendEvent is cancelled more than once per second on average.
In addition, looking at the stack trace of an event, we have this:

You actually only saved two calls from the 3 calls per handler. Two function calls have very very negligible effect on performance. Are you sure this makes any observable difference?

Stop focusing on minor things like preventing a few function calls. Premature optimization is the root of all evil. Instead, try to understand every line of code you write and make sense of them.
For example, if you run `new Config()` in PlayerMoveEvent, this will definitely lag the server, because you're opening a file stream every time, for hundreds of times per second. The problem is not from PlayerMoveEvent. The problem is from `new Config()`. I will equally think `new Config()` slows down your server even if it is in BlockBreakEvent or PlayerJoinEvent. (The problem is that you're using Config as a database; why not use libasynql?)

Not true. Can you possibly optimize anything in PHP (at the same time complexity)?

Also see my analysis in https://forums.pmmp.io/threads/reas...ng-the-myths-of-its-performance-impacts.5603/
Although that article might be slightly outdated, one thing isn't changed: It's just a few extra function calls, and as of PHP 7, the function call overhead is very small. What people usually think is that 4 or 5 function calls would have an impact on some event that involves dozens of other internal function calls.
My personal principle is, unless your optimization involves more than 1ms execution, more than 50% performance improvement or different time complexities, it is a premature optimization.
Just look at the other function calls in a single move event, then you'd see that a few extra function calls have no impact on the whole server.

Please evaluate the proportion of events that are cancelled. Do you really think preventing these calls would make a significant difference? It's very likely that a PlayerMoveEvent or a DataPacketSendEvent is cancelled more than once per second on average.
In addition, looking at the stack trace of an event, we have this:

You actually only saved two calls from the 3 calls per handler. Two function calls have very very negligible effect on performance. Are you sure this makes any observable difference?

Stop focusing on minor things like preventing a few function calls. Premature optimization is the root of all evil. Instead, try to understand every line of code you write and make sense of them.
For example, if you run `new Config()` in PlayerMoveEvent, this will definitely lag the server, because you're opening a file stream every time, for hundreds of times per second. The problem is not from PlayerMoveEvent. The problem is from `new Config()`. I will equally think `new Config()` slows down your server even if it is in BlockBreakEvent or PlayerJoinEvent. (The problem is that you're using Config as a database; why not use libasynql?)

Click to expand...

great explanation, i'm not clear on the premature optimizations though, can you provide an example? nice plug at the end

great explanation, i'm not clear on the premature optimizations though, can you provide an example? nice plug at the end

Click to expand...

If it's too complicated, let's think like this:

If it requires reading a file/Internet, try as hard as possible to make it async

If you are sure it could run more than 100000 loops (e.g. world editing), try to think of alternatives

It you suspect it slows down your server, test both versions a few times and see if there is obvious impact on TPS load. If you don't notice anything significant, don't try to optimize it.

PHP itself is already slow. Trying to optimize other parts doesn't solve the bottleneck problem. Most of the time, plugins are just glue code, and they do not need very excellent optimization. (PMMP itself needs optimization because it has grown far too complex, but plugins, even big ones like EconomyAPI or FactionsPro, do not require optimization unless they do stupid stuff like reading files on the main thread)