perf(log): 优化debug日志输出性能 #369
Conversation
- 在调试模式下条件性地输出 debug 日志，减少不必要的日志打印
|
@EquentR 感谢提交PR! |
|
@EquentR 看了下，修复的问题和思路没问题，我之前欠考虑了，主要问题抽象层 |
我看是二月份的消息了，想说一下我的看法，这里是否可以通过将新增的方法拆出来，独立出一个 control 接口来解决呢？默认实现使用 zlog 的日志级别进行判断，用户实现接口就是可选的，可以在之后自行选择是否去重新实现接口去设置这个 controller。 |
|
@Rinai-R 也就是说，组合出两个接口定义，用户根据需要去实现对应的接口是吗？框架内的实现就把新方法实现出来，在耗时日志中判断？ |
是的，我就是这个意思，如果用户有需求，可以自己去实现这个接口，重新设置这个实例，这样在耗时日志的地方就可以基于用户设置的实例来进行判断 |
|
可能并不是很好实现，目前框架日志使用zlog.Ins()函数获取当前的日志实例，若实现一个InsExtend()函数进行强转，若未实现DebugEnabled，可能需要更多额外的方式补全方法。我有空再研究一下吧，也麻烦您 @Rinai-R 如果有实现方式及时分享下😁 |
|
你要保证原有方法获取的实例还是原有的ILogger以保证兼容性，后面实现的新接口如何通过老方法zlog.SetLogger(zlog.ILogger)传入替换。还是说你的意思是完全不管老接口，直接使用新的接口实现DebugEnabled方法，在框架内调用时，使用不同的函数获取到新旧两个接口实现的同一个日志对象实例，达到兼容老接口的目的，而且新接口无需与老接口做兼容性适配？ |
我确实是这个意思，不过我想的是一个日志实例，一个控制实例，相当于依旧使用原来的日志实例，而我们在耗时日志的地方获取控制实例来进行判断，这样做实现起来比较简单，如果是这样的话有什么不妥吗？ |
|
按道理来说，如果用户实现的是原本日志接口，没有顺便实现extend接口函数，那么调用新函数拿取到的实例将出现类型转换错误，或者当出现没有实现时，我们使用默认的实现去解决这个问题（直接返回true）。那么还是会有debug日志hex部分耗时的性能问题。或者默认的实现返回false，那么当用户开启debug日志后，却不打印这条，也会导致与配置文件行为不一致的问题 |
这样的话，我们就必须要去判断用户自定义的日志的日志级别，但是目前没有这个接口，所以没办法获取，如果一定需要保证一致性，那么做到用户无感知就很难了。 |
|
是的，如果用户没法在一个日志实例中同时实现两个接口的方法，那么一致性将无法保证 |
所以这是一个退而求其次的方法，想要做到一致性，我们可能会不得不去破坏向下的兼容性，就很难去做到用户无感知，而想要做到用户无感知，就很难去做到一致性了。 |
issue：#366