Threading - Performance Question

Discussion in 'Plugin Development' started by Ziden, Jul 25, 2012.

Thread Status:
Not open for further replies.
  1. Offline

    Ziden

    Hi there.

    I have a simple question on a complex context.

    Lets say i detect i have an specific event that takes longer to process then i expect. What would happen in a server witch many online players (200+ for example) if i pass this event to an asynch runnable ? (bukkit runs it on otha thread, ddoesnt it ?)

    Something like

    event.setCancelled(true);
    Thread.start(); // uncancel it bukkit.blabla.callEvent(event)

    so this event would be delayed a bit in case of lag, and it could get a little async, but could this possibly increase tick rate ? Or im just smoking too much pot ?

    Thanks for the attention !
     
  2. Offline

    nisovin

    You can't make changes to an event in a separate thread, because the moment the main execution leaves your event handler, Bukkit will continue to process the event as normal. Any changes made to the event in a separate thread may or may not be made after Bukkit has already fully processed the event and moved on. You also certainly shouldn't call events from a separate thread, since other plugins won't know that the event is being called outside of the main thread.

    Additionally, most API methods cannot be used from a separate thread without causing major issues. It's certainly possible to offload some heavy internal processing to a separate thread as long as it isn't calling any Bukkit code.
     
    Ziden likes this.
  3. Offline

    pzxc

    Nisovin is correct... the best way I know to handle something that takes a longer amount of time to process than you'd like is to do it in batches.
    For example if you need for some reason to change 100,000 or more blocks at once, this will lag out your server, instead you can do it in chunks of 20,000 executed once every 10 seconds for 50 seconds. Or just do the first 20,000 blocks (or whatever your server can easily handle), then tell the user to run the command again to do the next 20k blocks.
     
    Ziden likes this.
  4. Offline

    Ziden

    Something ive noticed

    while(x<1000)
    player.sendBlockChange; x++

    if i logcally replace this by

    thread {

    while(x<1000)
    new runnable {
    player.sendBlockChange
    }
    }

    I get MAJOR lag difference, where server gets a freeze time in first , and the second code makes it run smooth. Why is that ?

    Ive tryed to read jvm scaling the tasks to it, it seems that when i call those 1000x runnables inside that thread, they are executed 'as soon as the cpu can' instead of 'now' , witch make em delay a little, and appear somehow async, but made it run way smoother.

    Im processing many bukkit information, its true plugins wont know its being processed but lets say in this case, this wouldnt matter if i do this in a specific event witch my other plugins wont interfere. (its a command, so pretty much i think it wont be a problem since it 'could' be executed any moment, or im talking bullshit on this ?).

    Lets say its a command that perform heavy operations witch does not involve modifyng stuff that doesnt come from my plugin, but uses bukkit API (such as the sendBlockChage etc etc).

    Thanks alot for the atention, and for magicspells. =]
     
  5. Offline

    Jnorr44

    I really hope your not smoking too much pot! haha

    I personally believe you should NEVER use a while loop in bukkit. It screws it up wayyy too much. Instead, figure out how to use a for loop/repeating task for what your trying to do.
     
  6. Offline

    Sagacious_Zed Bukkit Docs

    A while loop and a for loop has no performance difference, the biggest problem is a logical error with the conditional of the while loop.
     
  7. Offline

    Ziden

    anyway, whiles and fors have indeed assembly differences but not so much that materrs is something like 2 more executions for the startup nothing more during the loop

    thanks for ur attention, but back to topic ^^
     
Thread Status:
Not open for further replies.

Share This Page