正文
这种组合允许用户利用 C++ 的高性能特性进行日志数据的输入和处理。这种方案特别适合需要实时处理大量日志的场景，能够显著降低延迟并提升性能。
SPL（SLS Processing Language) 处理插件则提供了一种直观且强大的方式进行数据分析和处理。这种组合不仅提升了处理复杂性的能力，同时也简化了用户的操作体验。
通过结合 C++ Input 插件与 Golang 拓展处理插件，用户可以充分利用两者的优势。C++ 插件在数据采集过程中提供高性能的采集能力，而 Golang 插件则为数据处理增添了灵活性。
Golang Input 插件最大的优势是支持多种数据源，包括 Systemd、 Kafka、Win event 等，这种组合可以最大程度上适配多种多样的数据源。
流水线配置热加载隔离
LoongCollector采用总线模式，按功能划分线程。具体来说，根据流水线的形态，LoongCollector共有三大工作线程：Input Runner线程、Processor Runner线程和Flusher Runner线程，分别负责运行所有流水线的输入插件、处理插件和输出插件，各个线程之间通过缓冲队列进行连接。为了保证流水线之间的公平性和隔离性，LoongCollector进一步采用如下设计：
基于上述描述，LoongCollector的总线模式示意图如下：
但是总线模式，势必也对多租场景的隔离带来更大的挑战。从线程方面进行隔离是最简单的，但是多线程势必带来资源占用的成倍增长，这个是作为可观测数据采集器无法接受的。
LoongCollector 在采集配置整体调度，Flusher 线程资源分配的调度上，进行了深度优化，在总线模式下，最大程度上保证了多租能力。
iLogtail 在采集配置变更的情况下，采用的是 Stop The World 的方式，所有采集配置全部暂停，重新加载，然后重新启动。这样子在多个团队或者多个业务共用一个 iLogtail 实例的情况下，会有相互影响。比如业务 A 和业务 B 共用一个 iLogtail 实例，业务 A 的同学在不断调试采集配置，在调试阶段必然会对业务 B 的采集产生一定的影响。
LoongCollector 对流水线的生命周期管理进行了进一步优化，只对于有变化的 Pipeline 采用新旧替换的方式，其他没有变化的 Pipeline 保持不变，最大程度上保证采集配置变更影响最小化，避免 Stop The World 对整体的影响。
CPU 平均降低 35%，内存平均降低 10%
极简单行模式下，相同流量资源使用比较（柱值越低越好）
可以看到无论是 CPU 还是内存，LoongCollector 相比 iLogtail 都有比较大的优势。尤其是 CPU，LoongCollector 比 iLogtail 平均降低 0.15C；内存的话，在低流量场景，LoongCollector 优势不太明显，但是在高流量场景下，内存占用降低 10%左右。
核心场景极限采集速率平均提升 80%
文件采集
由图可以看到，在典型文件采集场景下， LoongCollector 无论是单线程还是多线程的场景下，采集性能对比 iLogtail 都有非常大的提升，单线程平均提升 40%，极简场景下提升 80%；多线程场景下提升更加明显，平均提升 80%。
