JS: Make the edges of API-graphs into IPA types #7180
Conversation
2dfa18c
to
97ee8d8
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 had also thought about making this change for Ruby, so perhaps I should give it a go. |
The bad join orders could still happen if we just eliminate the binding sets and cache the public API. But I'll give it a go. |
I tried two experiments where I removed the IPA type. 1: Just 2: Same code as the current PR, but revert back to labels as strings (implementation). |
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
cachethe 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 predicatesandoptimizations in global data flowcommits have no impact on performance on their own.(Evaluation of just those two commits).
And the
make ApiLabel into a IPA typecommit also has no impact on performance on its own (evaluation).The text was updated successfully, but these errors were encountered: