I just set up WarmRoast, and I've been having fun just poking around. I noticed that a reasonably significant amount of time is spent giving the world context, which seemed odd to me. Even stranger, it was almost all spent on String.intern(). Admittedly, I didn't even know what string interning was until I Googled it. But I think what I've learned is interesting, so I wanted to share it.

java-performance.info - String.intern in Java 6, 7 and 8 – string pooling

The string pool is implemented as a fixed capacity hash map with each bucket containing a list of strings with the same hash code.

-XX:StringTableSize=N, where N is the string pool map size

You must set a higher -XX:StringTableSize value (compared to the default 1009 [60013 since Java7u40] ) if you intend to actively use String.intern() – otherwise this method performance will soon degrade to a linked list performance.

Here's a WarmRoast screenshot. It shows that 20.92% of the time in hasPermission is spent calling the highlighted String.intern(). If you add up the time spent on all the calls to String.intern() (marked by green dots), you get the entirety of WorldCalculator.giveApplicableContext, which itself makes up 36.4% of hasPermission.
Imgur

So, at least for this particular callsite of hasPermission, 36.4% of the time is spent on String.intern(), and that's not including the call at the very bottom of the screenshot.

Since it's dependent on the number of entries in the string pool, the performance will vary based on the number of permission nodes (which are also interned apparently) and other plugins (for example, getDeclaredField calls String.intern).

My previous profiling of these methods showed String interning to be beneficial, but I hadn't considered the impact of a higher # of strings populating the pool.

I'll revert the change in the ContextSet implementations at least. I think it's probably worth keeping it on instances of Node.