ExtFilterMatcher 匹配类结构时希望能根据用户的配置省略部分操作

[z3tta]

目前的实现，在 com.alibaba.jvm.sandbox.core.util.matcher.ExtFilterMatcher#matchingClassStructure 里，是一定要执行以下两个操作的：

1. com.alibaba.jvm.sandbox.core.util.matcher.structure.ClassStructure#getFamilyInterfaceClassStructures
2. com.alibaba.jvm.sandbox.core.util.matcher.structure.ClassStructure#getFamilyAnnotationTypeClassStructures

如图：

但实际上如果用户在创建 EventWatchBuilder 时没有通过 hasInterfaceTypes 与 hasAnnotationTypes 进行声明，后续的操作是用不到上面获取到的对应数据的，即下图中选定的两个条件恒真，与入参具体数据无关：

而 getFamilyInterfaceClassStructures 与 getFamilyAnnotationTypeClassStructures 这两个操作的开销还挺大的，尤其是在对大量类进行增强的场景下：

故希望在用户对需要增强的类没有声明 hasInterfaceTypes 与 hasAnnotationTypes 时，不执行这两个操作，预计 transform 的效率能提升 30% ~ 50%

[oldmanpushcart]

收到建议，我们在v1.4.0版本实现

[XHao]

感觉subClass也可以顺带给处理了！
如果在ClassStructureByASM上引入Cache，可以大大缓解开销，特别是启动加载的情况。

[XHao]

@oldmanpushcart 下面这一步是不是会抵消上面说的优化？

// UnsupportedMatcher
private boolean isStealthClass(final ClassStructure classStructure) {
        return takeJavaClassNames(classStructure.getFamilyAnnotationTypeClassStructures())
                .contains(Stealth.class.getName());
    }

[oldmanpushcart]

@XHao 会...谢谢提醒，T_T，我再仔细测试下，我的不严谨，sorry

[the-wang]

感觉subClass也可以顺带给处理了！ 如果在ClassStructureByASM上引入Cache，可以大大缓解开销，特别是启动加载的情况。

赞同

[oldmanpushcart]

1.4.0版本已经优化，希望继续反馈，我们继续迭代。