Bug Slow Method Calls

Discussion in 'Developer Support' started by Cloud, Feb 11, 2016.

Thread Status:
Not open for further replies.
  1. Certain method calls are known to be unacceptably slow, if you encounter any that are not on the list and don't themselves invoke methods in the list than please post notifying me.
    • GameObjects.getLoaded() - Significantly faster than it used to be
      • GameObjects.getLoadedOn and getLoadedWithin can be used to search a smaller area which is significantly faster. GameObject queries automatically search the smaller area when a coordinate or area is passed in for the search parameter.
      • Specifying a type when querying for GameObjects is also a way to drastically speed up a query. It's a much faster check than name and/or actions because it doesn't require loading any definitions.
    • Interfaces.getLoaded()
      • Specifying the container can vastly reduce the amount of calls that need to be made. This optimization is automatically applied to queries.
    • ActionBarQueryBuilder.names(name).results()
      • Queries interfaces way more than necessary to get the name of the action in the slot
    • House#isInside - Only OSRS is slow
      • Relies on a GameObjectQuery for portals on OSRS
    #1 Cloud, Feb 11, 2016
    Last edited: Apr 11, 2016
  2. Loading interfaces are slow aswell.
    I have tested a lot of loading several game elements like npcs, gameobjects, players etc.
    The only two categories that were very slow are GameObjects (as stated in OT) and Interfaces.

    Here are some benchmarks:

    Here I did basic query calls like Players.newQuery().results(). No filtering or sorting.
    Code (Text):
    1. Players: 1ms
    2. GameObjects: 13523ms
    3. Npcs: 20ms
    4. Inventory: 2ms
    5. ActionBar: 11ms
    6. Interfaces: 2020ms
    This one is a bunch of steps taken to drop an item with the actionbar. There are several validations that could make sense.
    Code (Text):
    1. isLoggedIn(): 0ms
    2. getContinue(): 1540ms
    3. querying: 0ms
    4. getting item: 1ms
    5. gamemode check: 0ms
    6. item name: 0ms
    7. slot: 3791ms
    8. activating: 1233ms
    9. total: 6572ms
    ChatDialog.getContinue() is clearly querying interfaces.
    Retrieving a slot in the actionbar requires interfaces to be queried aswell.
    I am not sure about activating the slot, @Cloud can you confirm anything related to interfaces?

    EDIT: Of course the calls are not requiring the exact same amount of time every time, but it should be clear which ones are outstanding.
    Arbiter likes this.
  3. Interfaces could also be slow because of the sheer amount of calls that need to be made when a container isn't specified. If you specify a container(s) it'll only build the components for the relevant containers but a simple Interfaces.getLoaded() call will have to build the entire interface tree.
  4. Are API calls like getContinue() specified aswell? If so, I am wondering why it takes that long too.
  5. Those ones specifically were designed to be extremely robust and because of that the containers weren't specified, however they will be in the next release.

    Which method calls are these?
    1. slot: 3791ms
    2. activating: 1233ms
  6. 1. ActionBar.newQuery().names(name).results().first();
    2. slot.activate();
    slot being the action slot from 1.
  7. RegionPath in RS3 (Other pathing and gametypes haven't been tested) is really slow. Building the path takes 9 seconds. performing step() takes 13 seconds. Also, step() fails very often so you sometimes end up waiting over a minute for it to even step.

    #7 Aidden, Feb 15, 2016
    Last edited: Feb 15, 2016
  8. RS3 or OSRS, please start providing that information.
  9. Modified original post.
  10. @Cloud
    Interactable#isVisible() (or visibility).
    Found that out while querying NPCs for visibility, which took terribly long.
    Maybe that's the cause for interaction to be slow aswell if it also checks for visibility.
  11. GameObject's are now over 90% faster in OSRS so they will be removed from this list once RS3 has similar performance.

    I have a request for you developers though, I need an efficient replacement for House.isInside. It currnetly relies on if it can detect at least one portal and there should be a more efficient technique that doesn't require a query. Perhaps a varp/varpbit or some other piece of information.
  12. Are you serious? There's a varp that i use for it lol. I thought that's what you were using.
  13. Please provide it to me. Is that an OSRS or RS3 solution? Can you find a solution for both game modes?
  14. Unless the varp isn't perfect?
    --- Double Post Merged, Feb 23, 2016, Original Post Date: Feb 23, 2016 ---
    I can't look into it atm as i'm about to go to bed, but i was using it for RS3, not sure if it works for OSRS or not.
  15. Please report back sometime tomorrow then, thanks.
  16. This is what i had
    Code (Text):
    2. Varps.getAt(82).getValue() == 385
    And i just realized i can't check either game mode now as i don't have membership. Someone else might be able to though.
  17. I will be on it in one hour or two if no one got anything in the meantime
    --- Double Post Merged, Feb 24, 2016, Original Post Date: Feb 24, 2016 ---
    If I may make a suggestion at this point @Arbiter, add a varp listener to the devkit lmao
    --- Double Post Merged, Feb 24, 2016 ---
    Alright @Cloud
    Varp index 82 in RS3 is apparently in what region the player stands in. 385 seems to be the region of the player owned house.
    I couldn't figure anything out for OSRS because either the Varp listener is broken or OSRS doesn't use varps for anything (I tried a lot of things that would HAVE to change a varp, nothing changed though).
  18. @Cloud Npc interactions are slow and inacurate too...
    --- Double Post Merged, Mar 27, 2016, Original Post Date: Mar 27, 2016 ---
    very very slow. One interaction takes 20-30 seconds.
  19. Have you been updating your bind.jar as well as spectre.jar? The latest one is at V1.0.34's changelog.
  20. yes. but my is latest: V1.0.35?
Thread Status:
Not open for further replies.

Share This Page