Tikv日志创建优化：跳过get_entry_header中的logger初始化

在分布式KV存储引擎Tikv的性能优化过程中，开发团队发现了一个值得关注的性能瓶颈点。通过火焰图分析，发现在处理raft日志条目时，get_entry_header函数中创建日志记录器的开销几乎与解析protobuf消息相当，这显然是一个可以优化的性能热点。

在当前的实现中，SimpleWriteReqDecoder::new方法会初始化一个日志记录器，但这个记录器实际上仅用于记录极少发生的panic情况。从代码逻辑来看，这个日志记录器的创建并非必要操作，因为：

1. 它只在构造函数发生panic时才会被使用
2. panic本身就是极少发生的情况
3. 即使发生panic，标准库自带的panic处理也足够

这种设计在性能敏感路径上引入了不必要的开销。每次处理raft日志条目时，都需要为这个几乎不会使用的日志记录器分配资源，包括内存分配和初始化操作。在分布式系统的高并发场景下，这种微小的开销会被放大，最终影响整体吞吐量。

优化方案很直接：完全移除这个日志记录器的创建。这不会影响系统的可靠性，因为：

1. 系统原有的错误处理机制依然有效
2. panic情况会被标准库捕获并处理
3. 关键路径上的性能得到提升

这种优化属于典型的"零成本抽象"思想，即在保证功能完整性的前提下，移除不必要的开销。对于像Tikv这样的高性能存储系统，这类优化尤为重要，因为核心路径上的每一个CPU周期都可能影响整体性能。

从系统设计角度看，这也提醒我们在性能敏感路径上要谨慎使用日志记录。日志虽然是可观测性的重要组成部分，但不应该成为性能瓶颈。合理的做法是将关键路径上的日志记录保持在最低限度，或者采用异步日志等不影响主线程性能的方案。

这个优化虽然看似微小，但在分布式系统的高并发场景下，这类细小的改进累积起来可能带来显著的性能提升。这也体现了性能优化工作的特点：通过细致的分析和测量，找出并消除那些不易察觉但累积效应显著的开销点。