Filter apply blocks/freezes the browser for several seconds

Applying a filter with a large member selection blocks the browser for several seconds. The duration scales with the number of selected members.

Browser-profiling: the blockage is one synchronous task of 6,030 ms inside the Apply click handler. 5,973 ms of that, 99 percent, is spent in a single Array.prototype.some() in flexmonster.full.js. Our own code accounts for 23 ms across the whole profile. No request is involved — select only starts after the freeze has ended and returns in 2 ms.

The method is A3() in 2.9.136:

A3(c,d){return 0==d.length?!1:d.reduce((g,k)=>{
if(c.some(n=>n==k))return g;
const m=this.Ac.ya(k).children;
return g&&this.A3(c,m)},!0)}

It is called with the selected member ordinals and all top-level members of the hierarchy, i.e. the "if everything is selected, the filter can be dropped" check. c.some(...) is a linear scan of the full selection list per visited node, so the cost is O(#members x #selected) — on a flat hierarchy with tens of thousands of members that is hundreds of millions of comparisons. The reduce also doesn't break once the result is determined.

We understand the intent: dropping the filter avoids sending a large member list and makes the query cheaper. But the cost is paid on every apply, including when the answer is "no", and the query it saves took 2 ms in our profile. In the common case of "many but not all members selected" the full price buys nothing.

Two questions:

1. Is there any option to switch this check off, so that the filter is simply sent as selected? We did not find one in the report options or the API.
2. If not, could the check be optimised in the product? Indexing the selection once into a Set and exiting early instead of using reduce brings it down by roughly three orders of magnitude in a standalone reimplementation. If arbitrary value types have to be supported there, the fast path can be guarded by a typeof check with a fallback to the current scan.

We would rather not patch node_modules locally. Note also that we cannot simply skip the call on our side — the return value appears to feed internal filter state, and the whole sequence runs inside your click handler before any event we could hook into.