What causes lag in most plugins?

Discussion in 'Plugin Development' started by Developerjohn, Dec 23, 2013.

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

    Developerjohn

    I've been seeing lots of people asking why they get lag spikes in their plugins, and wondering how I can avoid these in the future. What are your tips on how I can stop these mistakes when coding?:rolleyes::confused:
     
  2. Offline

    1Rogue Retired Staff

    Bad coding practices. Heavy processing on a single stack. Inefficient solutions to problems.

    Overall you simply need to observe your code, and think "in what way can I do this with less object creation / operations".
     
    ZeusAllMighty11 likes this.
  3. Offline

    RawCode

    benchmark and debug your code, ever if everything looks OK.
     
  4. Offline

    DrBowe

    More often then not, most issues come from really basic coding mistakes. Leaking memory, poorly optimized loops, expensive operations being used far too often for the server to reliably keep up, etc.

    9 times out of 10, I'd argue that most plugin lag comes from really avoidable mistakes--and is hardly ever an issue of using a slightly 'less optimal' approach to a problem (because most servers aren't large enough for a slight millisecond difference to matter). Another common source would most likely be any plugin that makes massive changes to the world itself. Mass-conversion of blocks, or a per-tick block update can be very taxing on a server' resources.

    As for tips? Simply put, always try to keep optimization in mind when designing a plugin. I'm not sure that there are any specific tips. The only thing I can think of is to learn the basics of 'multi-threading' (and, more importantly, the dangers of doing it improperly) as this can help you with some of the 'heavy math' based lag you may or may not encounter. That being said, it's also a fairly heavy concept itself and can take quite a while to truly understand it.
     
  5. Offline

    CubieX

    - Whenever using a loop, think about how to make it efficient and break it early, when you got your data.
    - If you have heavy calculations, you can often swap them out to a separate thread, to not stall the main thread.
    - Communication with a remote database can cause heavy lags. Make queries asynchronously whenever possible.
    - Keep code in event handlers as short as possible and repeating timer tasks as slow as possible for your application.
    - Be cautious when using the PlayerMoveEvent. Generally avoid per-tick-checks whenever possible.
    - If you need to access or read data frequently, don't read directly from a file or database every time.
    Instead cache this data in HashMaps or Lists to keep them in your RAM for fast access.

    A good way to monitor the CPU time your plugin consumes each tick or in certain situations,
    you can use a profiler, or what I do: I use NoLaggs built-in function "examine" to generate records of my plugins.
    With this you can easily find time waster in your plugin.
     
    Chlorek likes this.
  6. Offline

    Chlorek

    Listen to CubieX , well said!
     
  7. Offline

    ZeusAllMighty11 Retired Staff

    * Lack of multithreading where possible
    * Inefficient loops
    * Constant calls to expensive functions within the Bukkit API (Such as setBlock() )
    * Constant querying when not necessary
    * Constant calls to load a file, grab data, unload. Over and over and over, I see this on the forums.
    * Lack of java knowledge..
     
  8. Offline

    Boomer

    Breaking out of events as early as possible with fewest, best checks possible as well, before diving into meaty code that needs to dig deep through objects (player> inventory> interate inventory> etc)

    Seen some bad codes that go through all the tests to then say "and is all of this that has been met, finally, after looping.. does it happen while the block at thislocation is dirt? No, okay then skip it" when that event gets called by everyone all the time, dirt only 5% of the time, and people in that situation only 1% of the time its dirt. Reject moving along if the block isn't dirt, and thats 95% of the calls to it that dont have to execute more code.

    Figure out conditions that will let you escape ASAP from the event with biggest yes/no slices with the simplest checks possible.. anything not ejected then continues on to the more meaty code. Less time spent even having to check one thing that it shouldn't have to, more cycles for everythign else on the server.

    ^That being good ideas to chop out, not what causes. My edit just brings up a blank screen...

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 5, 2016
Thread Status:
Not open for further replies.

Share This Page