perf(log): 优化debug日志输出性能

[EquentR]

• 在调试模式下条件性地输出 debug 日志，减少不必要的日志打印

issue：#366

[aceld]

@EquentR 感谢提交PR!

[aceld]

@EquentR 看了下，修复的问题和思路没问题，我之前欠考虑了，主要问题抽象层ILogger() 增加了接口，确实存在无法向下兼容的问题，可能会导致升级用户编译的问题，这块看看如何做到用户无感知，或者兼容写法，容我再思考思考哈~

[Rinai-R]

@EquentR 看了下，修复的问题和思路没问题，我之前欠考虑了，主要问题抽象层ILogger() 增加了接口，确实存在无法向下兼容的问题，可能会导致升级用户编译的问题，这块看看如何做到用户无感知，或者兼容写法，容我再思考思考哈~

我看是二月份的消息了，想说一下我的看法，这里是否可以通过将新增的方法拆出来，独立出一个 control 接口来解决呢？默认实现使用 zlog 的日志级别进行判断，用户实现接口就是可选的，可以在之后自行选择是否去重新实现接口去设置这个 controller。

[aceld]

@EquentR 看了下，修复的问题和思路没问题，我之前欠考虑了，主要问题抽象层ILogger() 增加了接口，确实存在无法向下兼容的问题，可能会导致升级用户编译的问题，这块看看如何做到用户无感知，或者兼容写法，容我再思考思考哈~

我看是二月份的消息了，想说一下我的看法，这里是否可以通过将新增的方法拆出来，独立出一个 control 接口来解决呢？默认实现使用 zlog 的日志级别进行判断，用户实现接口就是可选的，可以在之后自行选择是否去重新实现接口去设置这个 controller。

@Rinai-R 确实是一个好办法

[EquentR]

@Rinai-R 也就是说，组合出两个接口定义，用户根据需要去实现对应的接口是吗？框架内的实现就把新方法实现出来，在耗时日志中判断？

[Rinai-R]

@Rinai-R 也就是说，组合出两个接口定义，用户根据需要去实现对应的接口是吗？框架内的实现就把新方法实现出来，在耗时日志中判断？

是的，我就是这个意思，如果用户有需求，可以自己去实现这个接口，重新设置这个实例，这样在耗时日志的地方就可以基于用户设置的实例来进行判断

[EquentR]

可能并不是很好实现，目前框架日志使用zlog.Ins()函数获取当前的日志实例，若实现一个InsExtend()函数进行强转，若未实现DebugEnabled，可能需要更多额外的方式补全方法。我有空再研究一下吧，也麻烦您 @Rinai-R 如果有实现方式及时分享下😁

[Rinai-R]

可能并不是很好实现，目前框架日志使用zlog.Ins()函数获取当前的日志实例，若实现一个InsExtend()函数进行强转，若未实现DebugEnabled，可能需要更多额外的方式补全方法。我有空再研究一下吧，也麻烦您 @Rinai-R 如果有实现方式及时分享下😁

@EquentR 为什么需要转换？我觉得新接口的实现实例可以使用一个单独的实例而不是通过现有的日志实例来转换，或者我哪里理解错了，请指出一下😉

[EquentR]

你要保证原有方法获取的实例还是原有的ILogger以保证兼容性，后面实现的新接口如何通过老方法zlog.SetLogger(zlog.ILogger)传入替换。还是说你的意思是完全不管老接口，直接使用新的接口实现DebugEnabled方法，在框架内调用时，使用不同的函数获取到新旧两个接口实现的同一个日志对象实例，达到兼容老接口的目的，而且新接口无需与老接口做兼容性适配？

[Rinai-R]

你要保证原有方法获取的实例还是原有的ILogger以保证兼容性，后面实现的新接口如何通过老方法zlog.SetLogger(zlog.ILogger)传入替换。还是说你的意思是完全不管老接口，直接使用新的接口实现DebugEnabled方法，在框架内调用时，使用不同的函数获取到新旧两个接口实现的同一个日志对象实例，达到兼容老接口的目的，而且新接口无需与老接口做兼容性适配？

我确实是这个意思，不过我想的是一个日志实例，一个控制实例，相当于依旧使用原来的日志实例，而我们在耗时日志的地方获取控制实例来进行判断，这样做实现起来比较简单，如果是这样的话有什么不妥吗？
按照你的方法也很好，不过感觉实现起来麻烦一点

[EquentR]

按道理来说，如果用户实现的是原本日志接口，没有顺便实现extend接口函数，那么调用新函数拿取到的实例将出现类型转换错误，或者当出现没有实现时，我们使用默认的实现去解决这个问题（直接返回true）。那么还是会有debug日志hex部分耗时的性能问题。或者默认的实现返回false，那么当用户开启debug日志后，却不打印这条，也会导致与配置文件行为不一致的问题

[Rinai-R]

按道理来说，如果用户实现的是原本日志接口，没有顺便实现extend接口函数，那么调用新函数拿取到的实例将出现类型转换错误，或者当出现没有实现时，我们使用默认的实现去解决这个问题（直接返回true）。那么还是会有debug日志hex部分耗时的性能问题。或者默认的实现返回false，那么当用户开启debug日志后，却不打印这条，也会导致与配置文件行为不一致的问题

这样的话，我们就必须要去判断用户自定义的日志的日志级别，但是目前没有这个接口，所以没办法获取，如果一定需要保证一致性，那么做到用户无感知就很难了。
所以我觉得 extend 接口的实例不需要与原来的日志实例进行相互转换，而是独立开来，我们调用获取的实例依旧是默认的日志实例，关于原本的日志实例我们不用管，只需要用新的接口实例去判断日志级别即可，他专注于负责日志级别的判断，另一个原本的日志实例负责打印日志，但是这样没办法做到一致性，必须要用户自己去实现 extend 接口并且去 SetExtendIns 才行

[EquentR]

是的，如果用户没法在一个日志实例中同时实现两个接口的方法，那么一致性将无法保证

[Rinai-R]

是的，如果用户没法在一个日志实例中同时实现两个接口的方法，那么一致性将无法保证

所以这是一个退而求其次的方法，想要做到一致性，我们可能会不得不去破坏向下的兼容性，就很难去做到用户无感知，而想要做到用户无感知，就很难去做到一致性了。
但是两个方法都是为了避免耗时的日志，都是需要去实现这样一个方法，只是强制和不强制的关系。