On Wed, Dec 18, 2024 at 1:39 AM Xuelei Fan <[email protected]> wrote:
> On Tue, Dec 17, 2024 at 6:45 PM Martin Balao <[email protected]> wrote: > >> On Wed, 18 Dec 2024 00:35:38 GMT, Xue-Lei Andrew Fan <[email protected]> >> wrote: >> >> > Not to mention the performance impact. >> >> I am not sure if you mean the performance impact of having to make sure >> that the Filter is not set, or the performance impact of having the Filter >> disabled. For the latter, there won't be any impact. >> > > I may not agree because the filter checking was inserted everywhere, and > the checking will be performance 2 or more times for each service > retrieval. Even if the filter is disabled, the filter checking code is > still there. > The calls that you see to ProvidersFilter::isAllowed include a fast-path to handle a disabled filter. When the filter is disabled, the ProvidersFilter::filter field is null. Because this field is final, it's easy for a JIT compiler to remove calls altogether —the rest of ProvidersFilter::isAllowed is dead code and the (empty) method can be inlined—.
