Keith pointed one good idea, converting O(N^2) to O(2N) where N is # of DFG nodes in a basic block.
It's worth trying!
I believe this improves compile time of JetStream2/octane-zlib.
I'm pretty sure that one of JetStream2/octane-zlib function takes very long time to be compiled and it blocks DFG compilation pipeline and effectively blocks the following compile requests for small hot functions.
When I added AI mitigation to my working copy, CNN page is improved, but still it was laggy.
So, fixing AI algorithm does not offer much for CNN page. CNN page's script is huge, and anyway we should not handle it in DFG.
I think reducing the threshold is the right way to fix CNN page.
On the other hand, we have another compile time problem in JetStream2/octane-zlib.
I know that one of JetStream2/octane-zlib function takes very long time to be compiled and it blocks subsequent DFG compilation requests for small hot functions.
Interestingly, according to the A/B test, the above AI mitigation has performance problem in JetStream2/octane-zlib.
This fact means that JetStream2/octane-zlib has very large basic block which has PutStructure etc., but if we do conservative analysis onto that, it largely regressed the performance of JetStream2/octane-zlib.
So, if we want to improve compile time in JetStream2/octane-zlib, fixing AI algorithm is the right choice.