Which will be less "laggy": Timers, or event check?

Currently, I need to create 13 timers for my plugin. One timer would be running every second, to check a player's flight and such, and the other 12 would range from every second to every fifteen or so seconds.

I'm trying to find the best way to handle this issue, and the issue the 12 timers are solving is checking if a player can fly there. The timer would iterate through arrays of players, and the arrays would have a total of over 100 people.

With events, I'd check when a player moved from or to a chunk, and check if he/she can fly in the chunk. But, this would be for every player's chunk move event, which would also be with over 100 people.

So, which way do you think would be best, performance wise?

Thanks for the help!

 

Colby l
I'm leaning towards a repeating task, but if you optimize enough, PlayerMoveEvent may be a bit better.

 

Assuming you're not referring to java.util.Timer, which you cannot safely use with the Bukkit API, why do you need to construct 12 separate repeatable tasks? Wouldn't one task set to a reasonable delay be sufficient? Splitting up work that can be achieved by a single PlayerMoveEvent handler sounds like premature optimization to me.

You should always be wary of PlayerMoveEvent, especially when you're dealing with a potentially large player base. It's fired extremely frequently, so you're pretty much forced to check for crossing of chunk boundaries before doing your own processing (in this case, checking flight status):

Code:java

public class ExampleMod extends JavaPlugin implements Listener {
    private static class ChunkCoordinate {
        public final int x;
        public final int z;
 
        public ChunkCoordinate(int x, int z) {
            this.x = x;
            this.z = z;
        }
    }
 
    // We have to store the previous chunk somehow
    private Map<Player, ChunkCoordinate> currentChunk = Maps.newHashMap();
    private Stopwatch watch = new Stopwatch();
 
    @Override
    public void onEnable() {
        getServer().getPluginManager().registerEvents(this, this);
    }
 
    @EventHandler
    public void onPlayerMove(PlayerMoveEvent e) {
        //watch.start();
        ChunkCoordinate old = currentChunk.get(e.getPlayer());
 
        // New chunk coordinate
        Location location = e.getTo();
        int chunkX = location.getBlockX() >> 4;
        int chunkZ = location.getBlockZ() >> 4;
 
        // Only do our thing if the chunk has changed
        if (old == null || old.x != chunkX || old.z != chunkZ) {
            System.out.println("New chunk for " + e.getPlayer());
 
            currentChunk.put(e.getPlayer(), new ChunkCoordinate(chunkX, chunkZ));
        }
        //watch.stop();
    }
 
    @EventHandler
    public void onPlayerChangedWorldEvent(PlayerChangedWorldEvent e) {
        // Clear the chunk - it no longer refers to the correct world
        currentChunk.remove(e.getPlayer());
    }
 
    @EventHandler
    public void onPlayerQuitEvent(PlayerQuitEvent e) {
        // Prevent memory leaks
        currentChunk.remove(e.getPlayer());
 
        System.out.println("Time consumed by handler: " + watch);
    }
}

But is this actually faster than a scheduled tasks? To find out, I installed NoLagg on a private server (CB 1.7.2) along with the test plugin above, logged in (with no other players online) and executed nolagg examine while running in a straight direction. That produced a 25 second timing report for every event handler by every plugin:

Code:

Total duration: 6.347 ms / 500 ticks
Average duration: 0.013 ms/tick
Event count: 1
Task count: 0
Plugin: ExamplePlugin

Extrapolating to 100 players, that would be over 0.013 ms/tick * 100 = 1.3 ms/tick, which is 2.6% of the time in a single tick (50 ms). That's a pretty significant overhead.

If you uncomment watch.start() and watch.stop(), you can also get a sense of of the time consumed by the method handler alone, excluding the inherent overhead of invoking an event method through reflection:

Code:

Total duration: 9.254 ms / 500 ticks
Average duration: 0.019 ms/tick
Event count: 1
Task count: 0
Plugin: ExamplePlugin
...
[01:04:50] [Server thread/INFO]: Time consumed by handler: 9,644 ms

Though it appears reflection has very little to do with it. It's the chunk checking that is time consuming.

Compare that to a simple repeatable task, set to 1 second:

Code:java

public class ExampleMod extends JavaPlugin implements Listener {
    @Override
    public void onEnable() {
        getServer().getScheduler().scheduleSyncRepeatingTask(this, new Runnable() {
            @Override
            public void run() {
                for (Player player : Bukkit.getServer().getOnlinePlayers()) {
                    // Do whatever
                }
            }
        }, 20, 20);
    }
}

The numbers are startling:

Code:

Total duration: 0.291 ms / 500 ticks
Average duration: 0.001 ms/tick
Event count: 0
Task count: 1
Plugin: ExamplePlugin

That's at least an order of magnitude less overhead than the PlayerMoveEvent solution. Of course, the repeatable task might miss the chunk change by a second or two, but is that kind of accuracy really necessary?

Still, don't forget, circumstances might change when you scale things up to 100 players. I recommend doing tests yourself, with the flight check included.

 

Very interesting report, thanks for the long, and nicely detailed response. The reasoning behind 12 timers was each timer had to be different, because each one would remove items from player's inventory as they fly. For example, a guest may have an item removed every second for flying, when a VIP+ may get an item removed only every 20 seconds.

Thanks again for the response!