On Tue, Dec 17, 2024 at 9:34 PM Martin Balao <[email protected]> wrote:
> 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—. > Hm, that would be nice if JIT could optimize it. Did you have a chance to verify it?
