I measured performance ofPriorityQueueusing a simple priority-queue micro benchmark with fastLinkJS. It does add/peek/poll 10000 numbers (in order from 0-10000, maybe inappropriate for priorityqueue.)

The performance change on wasm (red and purple bars) was okay: add/peek gets a bit slower (probably because of array expansion), but the overall performance with poll is much faster. 🎉

The problem is the execution performance on JS.
As you can see from the blue (main) and orange (this change) graphs, the performance on add/peek is about 10 times slower, andpoll is also degraded by 2 times.

null checks on innnerImpl

One problem is that, withlinktimeIf, the null check oninnerImpl has inserted everywhere$n($m_ju_PriorityQueue$().ju_PriorityQueue$__f_java$util$PriorityQueue$$innerImpl); The diff between main vs this branch, generated from the Scala code below:https://gist.github.com/tanishiking/9d0e24de18e994cae5e8742aa9749d98#file-foo-diff

Interestingly, withoutlinkeTimeIf on innerImplprivate val innerImpl: InnerArrayImpl = InnerArrayImpl.JSArrayImpl (green bar),innerImpl gets inlined and there's no null check on it. diff:https://gist.github.com/tanishiking/9d0e24de18e994cae5e8742aa9749d98#file-foo2-diff

linktimeIf should generate the same code as theinnerImpl = InnerArrayImpl.JSArrayImpl.

packagehelloworldimportjava.util.PriorityQueueobjectHelloWorld {defmain(args:Array[String]):Unit= {valpq=newPriorityQueue[Int]()for (element<-List(1,2,3,4,5)) {      pq.add(element)    }  }}

It's still slower

Withprivate val innerImpl: InnerArrayImpl = InnerArrayImpl.JSArrayImpl, the performance gets better (green bar), but it's still much slower thanmain.

I'm not sure why it's much slower with this diff 🤔https://gist.github.com/tanishiking/9d0e24de18e994cae5e8742aa9749d98#file-foo2-diff

linktimeIf should generate the same code as theinnerImpl = InnerArrayImpl.JSArrayImpl.

I managed to get this to happen by changinggenApplyTypeApply inGenJSCode.scala to

privatedefgenApplyTypeApply(tree:Apply,isStat:Boolean): js.Tree= {implicitvalpos= tree.posvalApply(TypeApply(fun@Select(obj, _), targs), args)= treevalsym= fun.symbol      symmatch {caseObject_isInstanceOf=>          genIsAsInstanceOf(obj, targs, cast=false)caseObject_asInstanceOf=>valtargetTpe= targs.head.tpe          objmatch {caseApply(fun,List(cond, thenp, elsep))if fun.symbol== jsDefinitions.LinkingInfo_linkTimeIf&&                thenp.tpe<:< targetTpe&& elsep.tpe<:< targetTpe=>valgenObj= genExpr(obj).asInstanceOf[js.LinkTimeIf]              js.LinkTimeIf(genObj.cond, genObj.thenp, genObj.elsep)(toIRType(targetTpe))(genObj.pos)case _=>              genIsAsInstanceOf(obj, targs, cast=true)          }caseObject_synchronized=>          genSynchronized(obj, args.head, isStat)case _=>          abort("Unexpected type application"+ fun+"[sym:"+ sym.fullName+"]"+" in:"+ tree)      }    }

That removes a spuriousjs.AsInstanceOf around thejs.LinkTimeIf, which prevents the module aliasing analysis done inIncOptimizer.scala.

(It's a rough draft; it should be cleaned up and tested in order to accept that change intomain.)

I'm getting back on this. Sorry for the delayed response, and thank you very much for addressing the issue about spuriousjs.AsInstanceOfs!

I found that, another significant performance degradation inadd is caused byfixUp implementation. It always traversed all the way up to the root node even after finding a suitable location. fixed indbfd7a7
(Interestingly, it wasn't a problem withoutinnerImpl, because JS will be optimized to stop traversing whenfixUp found the location).

Fixing thefixUp and applying your change, we could optimize Wasm without degrade the JS performance 🎉
Now there's a small diff between main and HEAD in JShttps://gist.github.com/tanishiking/5f7b24a1e4e3e724b85d5e60415bf1e4

Your change in#5168 (comment) looks good to me, maybe we can make another PR with tests?