JS: Make the edges of API-graphs into IPA types

[erik-krogh]

While looking at #6571 I kept running into performance issues related to API-graphs.
The RA would often contain an inverseappend[..], where it would do string-comparisons on every edge in order to extract the member-edges.
It sometimes took a lot of effort to avoid that bad join.

The obvious solution is to convert the edges into an IPA-type.
This gives a more complicated implementation, but it's an implementation where future use of API-graphs should perform better.
It also allows to cache the entire public API of API-graphs.

I encountered a bunch of bad join order from this refactoring, so those were fixed along the way.

---

A multi-threaded evaluation shows a limited performance improvement.
Running single-threaded shows a more noticeable performance improvement.

---

The cache more predicates and optimizations in global data flow commits have no impact on performance on their own.
(Evaluation of just those two commits).
And the make ApiLabel into a IPA type commit also has no impact on performance on its own (evaluation).

[asgerf]

It also allows to cache the entire public API of API-graphs.

Have you tried this without an IPA type? We could have a predicate containing all labels occurring the graph, and use that to eliminate the binding sets and cache everything.

[hvitved]

I had also thought about making this change for Ruby, so perhaps I should give it a go.

[erik-krogh]

It also allows to cache the entire public API of API-graphs.

Have you tried this without an IPA type? We could have a predicate containing all labels occurring the graph, and use that to eliminate the binding sets and cache everything.

The bad join orders could still happen if we just eliminate the binding sets and cache the public API.
Something like result = someAPINode.getASuccessor(API::Label::member(someName)) could still introduce an inverseAppend.

But I'll give it a go.

[erik-krogh]

It also allows to cache the entire public API of API-graphs.

Have you tried this without an IPA type? We could have a predicate containing all labels occurring the graph, and use that to eliminate the binding sets and cache everything.

I tried two experiments where I removed the IPA type.
Both experiments showed neutral performance, so I still think we should try the IPA types.

1: Just cache the public API (implementation).
Evaluations: multi-threaded, and single-threaded both show about neutral performance (0.993 and 1.001 respectively).

2: Same code as the current PR, but revert back to labels as strings (implementation).
Evaluations: multi-threaded, and single-threaded shows that there might be a tiny performance improvement (0.997 and 0.988 respectively).

[asgerf]

Ok, just a few comments otherwise LGTM

[asgerf]

Is there a reason for this to be abstract?

[erik-krogh]

No, there is not. Good point.
I'll make the class non-abstract.

[asgerf]

I'd like to avoid using the abbreviation "mod = module".

Suggested change

	class LabelMod extends ApiLabel {
	class LabelModule extends ApiLabel {

[asgerf]

Suggested change

	LabelMod mod(string m) { result.getMod() = m }
	LabelModule moduleLabel(string m) { result.getModule() = m }