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

Optimize NestedPackages by deferring sorting #513

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

BasiqueEvangelist
Copy link

NestedPackages uses a linear search to add in new entries right now. Unsurprisingly, this is really bad when there are a lot of entries.
This PR changes the tree node type to use a non-synchronized tree node class that defers sorting, which makes adding nodes a lot faster.

This is basically just a port of QuiltMC/enigma#84 (my own PR) to Fabric Enigma.

@NebelNidas NebelNidas mentioned this pull request Jun 15, 2023

@Override
public int getIndex(TreeNode node) {
return Iterables.indexOf(this.children, other -> this.comparator.compare(node, other) == 0);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this call checkSorted() as well, since the order of the node in the list before and after sorting may be different? (Or, if this is intended, perhaps a comment is in order.)

Also, why use Iterables.indexOf instead of List.indexOf? If the comparator is known to be consistent with equals (and the javadoc for Comparator recommends that comparators used with sorted collections be consistent with equals), then both ways should be equivalent. (Theoretically, List.indexOf would be faster by virtue of the List implementation taking advantage of impl. details.)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't the ClassEntry comparator be inconsistent with equals, though?
In any case, I'm probably just going to turn this into a manual for loop.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell, the ClassEntry comparators -- defined in ClassSelector#DEOBF_CLASS_COMPARATOR and used in DeobfPanel#<init>, and defined as a lambda in ObfPanel#<init> -- are both consistent with equals.

ClassEntry#equals checks if the parent and class name of the entry are equivalent; the comparators above compare using the full name of the class1, which is derived from the class name of the entry and of its parent. Because of that, if two ClassEntrys are equal in terms of equals, the comparators will also declare them equivalent (returning 0).

Though, that is the present state of the code; the future may possibly bring comparators inconsistent with equals, but I think that's improbable (and would already cause problems anyway, because then you'd have entries that don't equal themselves or are equal to other entries according to the comparator).

Footnotes

  1. In the ObfPanel comparator's case which compares the lengths of the full names first: if the two full names are equivalent, then necessarily the lengths are also the same.

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

Successfully merging this pull request may close these issues.

2 participants