Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WrappedDataWatcher#hasIndex too slow because of try/catch #850

Closed
MeGysssTaa opened this issue May 27, 2020 · 2 comments
Closed

WrappedDataWatcher#hasIndex too slow because of try/catch #850

MeGysssTaa opened this issue May 27, 2020 · 2 comments
Assignees
Labels

Comments

@MeGysssTaa
Copy link

Describe the bug
The current implementation of WrappedDataWatcher#hasIndex makes use of method public Object getObject(WrappedDataWatcher.WrappedDataWatcherObject object). In order for this method to return null, or, in other words, in order for hasIndex to return false, a NullPointerException or an InvocationTargetException must be thrown and handled:

(see screenshot 1)

This solution is slow in scenarios where hasIndex is called very often (for example, when using a custom data watcher to create cross-compatible packet NPCs):

(see screenshot 2)

To Reproduce
Steps to reproduce the behavior:

  1. Use method hasIndex of WrappedDataWatcher often enough, e.g. in a custom data watcher for cross-compatible packet NPCs.
  2. Create a Java Flight Recording.
  3. Enjoy a ton of NullPointerExceptions and even more InvocationTargetExceptions in the exceptions tab.

Expected behavior
I would really appreciate it if this method was faster and avoided use of any try/catch statements and exception handlers, so that it may be called very frequently without negative performance consequences.

Screenshots
code snippet of getObject

exception call stack snippet from JFR

Version Info
https://pastebin.com/7bi3qARm

Additional context
High load.

dmulloy2 added a commit that referenced this issue May 28, 2020
Use the map to check for indices instead of getting the object

Addresses #850
@dmulloy2
Copy link
Owner

@MeGysssTaa I appreciate the thoroughness. Give the latest dev build a try and let me know if it helps

@dmulloy2 dmulloy2 self-assigned this May 28, 2020
@MeGysssTaa
Copy link
Author

Works perfectly now, thank you and sorry for the delay in response!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants