yeah, all player updating is, is essentially a packet that a single player sends out to be written to the socket channel. so if you were to attach an event for updating or whatever to every single player and have some sort of system that fires those events in 600ms intervals you would be okay.
this could replace all processing for players completely, something like
Code:
Events.getSingleton().submit(new Event() {
@Override
public boolean fireWhen() {
// updating is needed every single tick, so always return true
return true;
}
@Override
public void fire() {
// updating logic here
}
// we need this event as long as the player is online
}.setRemoveOnFire(false));
really bad example, but you get the idea
although in those events, you would still have to loop through the local list to update it. there's no getting around looping lol, if you're trying to avoid them while programming... anything in java really you're not going to have a fun time
there would also have to be a strict order of the events, because in a traditional server everything is processed serially (besides updating which is done in parallel on servers that don't suck). you wouldn't want to have a player getting reset before they get updated, or getting pre-update logic fired after they're updated, etc.
all in all the idea sounds nice, but just too complicated to carry out and not worth it at all because you wouldn't see any performance benefits. you'd actually probably see better performance on the traditional servers that just do a normal loop through all of the entities
if you're looking for a way to reduce overhead (lag) then look at player updating. not at updating the local list but look at the update blocks, that is what eats up the entire cycle time especially appearance updating! be sure to cache data whenever you can (most importantly the update blocks themselves, i wrote i little tutorial on it here) and micro-optimizations do matter!!