开源纯C日志函数库iLOG3快速入门（五、与随手写的简单写日志函数的比较）

最新推荐文章于 2024-08-13 11:22:51 发布
最新推荐文章于 2024-08-13 11:22:51 发布
阅读量130 收藏
点赞数
文章标签： git python shell
原文链接：https://my.oschina.net/u/988092/blog/202240
版权

2019独角兽企业重金招聘Python工程师标准>>> hot3.png

前几天看到一个网友的评论：“这种一般自己实现个用用就行了 没必要整第三方库”。
的确，很多个人或公司都自己实现了简单写日志函数在产品中使用即可，一般不喜欢第三方库，一来认为第三方库代码多，势必影响性能，二来带来的不可预见的代码黑盒子，影响软件整体可靠。
这是一个广泛的论点，我并不否认它的存在合理性，但还是想对传统的简单写日志函数和iLOG3函数库做个比较，分两部分：性能和代码复杂度，看完后你会发现你会对日志函数库iLOG3感兴趣的。

一、性能

一般来讲，简单写日志函数肯定要比日志函数库要快，但是我分别做了压力测试，结果发现iLOG3竟然比简单写日志函数要快近一倍！下面是测试案例

随手写的最简单的写日志函数代码（源码包test目录下的bench_tiny.c） 
static int _WriteLogBase( char *c_filename , long c_fileline , int log_level , char *format , va_list valist )
{
    int        fd ;
    
    char        buf[ 1024 + 1 ] ;
    long        len ;
    time_t        tt ;
    struct tm    stime ;
    pid_t        pid ;
    unsigned long    tid ;        
    
    int        n ;
    
    /* 打开日志文件 */
    fd = open( "bench_tiny.log" , O_CREAT|O_APPEND|O_WRONLY , S_IRWXU|S_IRWXG|S_IRWXO ) ;
    if( fd == -1 )
        return -1;
    
    /* 组织日志内容 */
    time( & tt );
    localtime_r( & tt , & stime );
    pid = getpid() ;
    tid = (unsigned long)pthread_self() ;
    memset( buf , 0x00 , sizeof(buf) );
    len = snprintf( buf , sizeof(buf) , "%04d-%02d-%02d %02d:%02d:%02d | INFO  | %d:%lu:%s:%ld | %s\n" , stime.tm_year+1900 , stime.tm_mon+1 , stime.tm_mday , stime.tm_hour , stime.tm_min , stime.tm_sec , pid , tid , c_filename , c_fileline , "log" ) ;
    
    /* 输出日志 */
    n = write( fd , buf , len ) ;
    if( n == -1 )
        return -1;
    
    /* 关闭日志文件 */ /* 关键场合必须及时关闭文件，否则日志有丢失可能 */
    close( fd );
    
    return 0;
}

#define LOG_LEVEL_DEBUG        0
#define LOG_LEVEL_INFO        1
#define LOG_LEVEL_WARN        2
#define LOG_LEVEL_ERROR        3
#define LOG_LEVEL_FATAL        4

/* 以不同日志等级写行日志 */
int DebugLog( char *c_filename , long c_fileline , char *format , ... )
{
    ...
}

int InfoLog( char *c_filename , long c_fileline , char *format , ... )
{
    va_list        valist ;
    
    /* 暂不写日志等级过滤逻辑 */
    /* ... */
    
    /* 调用通用底层函数输出日志 */
    va_start( valist , format );
    _WriteLogBase( c_filename , c_fileline , LOG_LEVEL_INFO , format , valist );
    va_end( valist );
    
    return 0;
}

int ErrorLog( char *c_filename , long c_fileline , char *format , ... )
{
    ...
}

...
在我的环境里跑出这样的成绩 
$ rm -f *.log* ; sleep 1 ; time ./bench_tiny 10 10 10000 ; head -1 bench_tiny.log ; wc *.log* ; rm -f *.log*

real    0m21.863s
user    0m1.688s
sys     0m19.924s
2014-02-22 12:58:25 | INFO  | 2457:3086568336:bench_tiny.c:144 | log
1000000  8000000 69000000 bench_tiny.log
嗯，10个进程，每个进程开10个线程，每个线程循环调用函数InfoLog()一万次，花费21秒左右，共写出100万行日志，约6900万字节

现在轮到iLOG3出场，用源代码包中test目录下的压测示例test_press_mpt.c。
公平起见，把按文件大小转档关掉。 
// SetLogRotateMode( press , LOG_ROTATEMODE_SIZE );
开跑 
$ rm -f *.log* ; sleep 1 ; time ./test_press_mpt 10 10 10000 ; head -1 test_press_mpt.log ; wc *.log* ; rm -f *.log

real    0m13.745s
user    0m1.136s
sys     0m12.444s
2014-02-22 13:02:33 | INFO  | 2893:3086392208:test_press_mpt.c:120 | log
1000000  8000000 73000000 test_press_mpt.log
同样开10个进程，每个进程开10个线程，每个线程循环调用函数iLOG3里的InfoLog()一万次，花费13秒左右，共写出100万行日志，约7300万字节，你没看错，iLOG3日志函数库的日志输出性能比随手写的简单写日志函数快了近一倍。
为什么会这样呢？等我再对比完代码复杂度后一起总结 ^_^

二、代码复杂度

我们从iLOG3里的InfoLog作为入口一层层剥离下去，看一下写一次日志需要跑哪些路径，和随手写的简单写日志函数代码有哪些区别。 
/* 写普通信息日志 */
int InfoLog( LOG *g , char *c_filename , long c_fileline , char *format , ... )
{
    WRITELOGBASE( g , LOG_LEVEL_INFO )
    return 0;
}

/* 代码宏 */
#define WRITELOGBASE(_g_,_log_level_) \
    va_list        valist; \
    int        nret ; \
    if( (_g_) == NULL ) \
        return LOG_RETURN_ERROR_PARAMETER; \
    if( (_g_)->output == LOG_OUTPUT_FILE && (_g_)->log_pathfilename[0] == '\0' ) \
        return 0; \
    if( TEST_LOGLEVEL_NOTENOUGH( _log_level_ , (_g_) ) ) \
        return 0; \
    va_start( valist , format ); \
    nret = WriteLogBase( (_g_) , c_filename , c_fileline , _log_level_ , format , valist ) ; \
    va_end( valist ); \
    if( nret < 0 ) \
        return nret;

/* 写日志基函数 */
int WriteLogBase( LOG *g , char *c_filename , long c_fileline , int log_level , char *format , va_list valist )
{
    long        writelen ;
    int        nret ;
    
    if( format == NULL )
        return 0;
    
    /* 初始化行日志缓冲区 */
    g->logbuf.buf_remain_len = g->logbuf.buf_size - 1 - 1 ;
    g->logbuf.bufptr = g->logbuf.bufbase ;
    
    /* 填充行日志缓冲区 */
    if( g->pfuncLogStyle )
    {
        nret = g->pfuncLogStyle( g , & (g->logbuf) , c_filename , c_fileline , log_level , format , valist ) ;
        if( nret )
            return nret;
    }
    
    /* 自定义过滤日志 */
    if( g->pfuncFilterLog )
    {
        nret = g->pfuncFilterLog( g , & (g->open_handle) , log_level , g->logbuf.bufbase , g->logbuf.buf_size-1-1 - g->logbuf.buf_remain_len ) ;
        if( nret )
            return nret;
    }
    
    /* 打开文件 */
    if( g->open_flag == 0 )
    {
        if( TEST_ATTRIBUTE( g->log_options , LOG_OPTION_CHANGE_TEST ) || TEST_ATTRIBUTE( g->log_options , LOG_OPTION_OPEN_ONCE ) )
        {
            if( g->pfuncOpenLogFirst )
            {
                nret = g->pfuncOpenLogFirst( g , g->log_pathfilename , & (g->open_handle) ) ;
                if( nret )
                    return nret;
                g->open_flag = 1 ;
            }
        }
        else if( TEST_ATTRIBUTE( g->log_options , LOG_OPTION_OPEN_AND_CLOSE ) )
        {
            /* 打开日志文件 */
            if( g->pfuncOpenLog )
            {
                nret = g->pfuncOpenLog( g , g->log_pathfilename , & (g->open_handle) ) ;
                if( nret )
                    return nret;
                g->open_flag = 1 ;
            }
        }
    }
    
    /* 导出日志缓冲区 */
    if( g->pfuncWriteLog )
    {
        nret = g->pfuncWriteLog( g , & (g->open_handle) , log_level , g->logbuf.bufbase , g->logbuf.buf_size-1-1 - g->logbuf.buf_remain_len , & writelen ) ;
        if( nret )
            return nret;
    }
    
    /* 关闭日志 */
    if( g->open_flag == 1 )
    {
        if( g->output == LOG_OUTPUT_FILE || g->output == LOG_OUTPUT_CALLBACK )
        {
            if( TEST_ATTRIBUTE( g->log_options , LOG_OPTION_CHANGE_TEST ) )
            {
                if( g->pfuncChangeTest )
                {
                    nret = g->pfuncChangeTest( g , & (g->test_handle) ) ;
                    if( nret )
                        return nret;
                }
            }
            else if( TEST_ATTRIBUTE( g->log_options , LOG_OPTION_OPEN_AND_CLOSE ) )
            {
                /* 关闭日志文件 */
                if( g->pfuncCloseLog )
                {
                    nret = g->pfuncCloseLog( g , & (g->open_handle) ) ;
                    if( nret )
                        return nret;
                    g->open_flag = 0 ;
                }
            }
        }
    }
    
    /* 如果输出到文件 */
    if( g->output == LOG_OUTPUT_FILE )
    {
        /* 日志转档侦测 */
        if( g->rotate_mode == LOG_ROTATEMODE_NONE )
        {
        }
        else if( g->rotate_mode == LOG_ROTATEMODE_SIZE && g->log_rotate_size > 0 )
        {
            g->skip_count--;
            if( g->skip_count < 1 )
            {
                RotateLogFileSize( g , writelen );
            }
        }
        else if( g->rotate_mode == LOG_ROTATEMODE_PER_DAY )
        {
            RotateLogFilePerDate( g );
        }
        else if( g->rotate_mode == LOG_ROTATEMODE_PER_HOUR )
        {
            RotateLogFilePerHour( g );
        }
    }
    
    /* 清空一级缓存 */
    g->cache1_tv.tv_sec = 0 ;
    g->cache1_stime.tm_mday = 0 ;
    
    return 0;
}
以上可以看出两者路径基本一致，iLOG3的WriteLogBase也是格式化行日志缓冲区、打开日志文件、输出日志、关闭日志文件、日志转档处理，无非都是抽象成日志控制框架，即通过回调函数来挂接实现而没有直接调用具体功能函数，这样设计的好处是用户可以编写自己的打开输出关闭日志文件等函数来替代iLOG3默认挂接的来实现更灵活的日志控制。

好，现在我来解释一下为什么第三方的日志函数库iLOG3比自己随手写的简单写日志函数速度快近一倍的原因。

首先，日志函数库iLOG3的原型就是简单写日志函数扩充而来，所以它们的处理路径和基本逻辑差不多，但是iLOG3把作为函数库的很多耗时的配置解析等工作尽量都放在写日志前就预先处理好，真正写日志时跑的函数调用关系、运行逻辑路径等和简单写日志函数跑过的基本一致，可以理解成iLOG3写日志时调用的其实就是简单写日志函数，到此它们的性能就差不多了，然后，iLOG3拥有日志句柄这个数据结构，为缓存层等设计提供了方便，iLOG3内部做了大量严谨、精巧的性能优化，其中就包括时间缓存(保证缓存不会串日志)、字符串转换缓存、文件大小转档步进算法等，恰当受控的优化的效果是显而易见的，最终性能就比随手写的简单写日志函数要快了。

最后，再次展现一下我开发iLOG3的设计准则：
·作为软件的重要基础模块，日志函数库应尽量实现的轻便、简易和稳定，在保证高可靠性的前提下，高性能低影响是首要设计目标。提供多层API以及可选的外部配置文件方式使用。
·基本功能必不可少，如日志等级、行日志和十六进制块日志等，对性能和易用性影响较大的高级功能可不加尽量不加。（要不要实现日志转档是一个很纠结的问题，我一直坚持认为用运维shell来实现会更好，但迫于同类日志库的压力，我还是实现了）
·日志模块至少应分为两部分：核心和外部配置，中间用API胶合起来，便于扩展和灵活替换
·线程安全

是不是越看越心动了？那就赶紧下载来玩玩吧
首页传送门 : http://git.oschina.net/calvinwilliams/iLOG3
源代码包doc目录中包含了用户指南和参考手册，里面有更详尽的说明

声明：文本的写作目的并不是想说服大家改用第三方日志函数库来替代自己写的简单写日志函数，而是想带领大家深入探讨诸如写日志这类在某些场景中软件必备模块的一些思考，至于用不用iLOG3则需要你更多更全面甚至是非技术层面的考量。

转载于:https://my.oschina.net/u/988092/blog/202240

weixin_34248258
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
log4net_写日志_ASP.NET_MVC_WINFORM三合一DEMO
03-27
**日志记录在IT开发中的重要性** 在软件开发中，日志记录是不可或缺的一部分，它可以帮助开发者追踪程序运行状态，定位错误，优化性能，并提供关键的审计线索。`log4net`是一款广泛应用于.NET平台的日志框架，由...
C#写日志文件
05-26
在.NET开发环境中，日志记录是一项非常重要的任务，它帮助开发者追踪程序运行状态，调试错误，以及维护系统稳定性。C#作为.NET Framework的主要编程语言，提供了多种方式来实现日志功能，其中log4net是一个广泛使用...
开源纯C日志函数库iLOG3快速入门（八、如果你喜欢简单日志函数甚于日志函数库）...
weixin_34161032的博客
07-20 100
2019独角兽企业重金招聘Python工程师标准>>> ...
开源纯C日志函数库iLOG3快速入门（二、定制远程日志服务）
weixin_34214500的博客
02-13 145
2019独角兽企业重金招聘Python工程师标准>>> ...
转载_纯C日志函数iLOG3
williamwanglei的专栏
08-25 1101
iLOG3 是一个轻便易用、概念简单，高性能、多层接口、原生跨平台、（规范使用时）线程安全的遵循LGPL开源协议的标准 C 日志函数库。 基本特性如下： 原生跨平台，这意味着你的软件在日志层面上是可轻松移植的，目前支持WINDOWS & UNIX & Linux ，iLOG3会在不同的操作系统上做相应的实现和优化 五类日志等级 变参的日志函数和日志宏
开源纯C日志函数库iLOG3快速入门（三、日志过滤和转档后压缩）
weixin_34266504的博客
02-15 205
2019独角兽企业重金招聘Python工程师标准>>> ...
标准c快速日志函数库iLOG3 - 更新日志v1.0.5
weixin_34292924的博客
05-11 123
2019独角兽企业重金招聘Python工程师标准>>> ...
开源纯C日志函数库iLOG3快速入门（六、日志配置文件）
weixin_33862188的博客
02-27 160
2019独角兽企业重金招聘Python工程师标准>>> ...
基于机器学习的日志函数自动识别方法.pdf
09-24
首先，研究者系统地分析了广泛应用的大规模开源软件，总结出日志函数编写的主要形式，并从中提取不同形式之间的共性特征。这些特征可能包括函数名称、参数类型、返回值、注释内容等，它们反映了日志函数的一般模式。...
ilog-charts3d.rar_ILOG_ILOg charts_flex_ilog-elixir_ilog.charts3
09-24
五、ILOG Elixir与Charts 3D的结合 "Ilog-elixir"可能是指ILOG的Elixir产品，这是一个业务流程建模和优化工具。当ILOG Charts 3D与ILOG Elixir结合时，可以实现数据可视化与业务流程的无缝集成，帮助决策者更好地...
C Sharp Log4net日志记录配置教程.docx
11-23
它的主要优点在于灵活性、可扩展性和性能，使得开发者能够轻松地控制和管理应用程序的日志输出。以下是一个关于如何在C#项目中配置和使用log4net的详细教程。 首先，为了在C#项目中使用log4net，你需要获取log4net...
开源纯C日志函数库iLOG3快速入门（一、基本使用速览）
weixin_34119545的博客
02-10 294
2019独角兽企业重金招聘Python工程师标准>>> ...
基于iLog3的实时日志实现
reloner12的专栏
04-29 1017
这个封装类是为了不用跟傻X扯逼而创造的.......
git安装
qq_64782704的博客
08-10 833
版本控制是指对软件开发过程中各种程序代码,配置文件及说明文档等文件变更的管理,是软件配置管理的核心思想之一版本控制的主要功能是追踪文件的变更,它将什么时候,什么人更改了文件的什么内容等信息都一五一十的记录了下来,每一次文件的变更,文件的版本号都将增加,除了记录文件的变更之外,还可以用于解决企业中多人合作开发,代码管理共享的问题版本控制可以解决两个问题。
Chromium编译指南2024 - Android篇：前置要求（一）
守城小轩的技术窝棚
08-09 601
通过本篇文章，我们详细介绍了在 Android 平台上编译 Chromium 所需的前置要求，包括系统和硬件要求。确保您的开发环境满足这些要求，是成功编译 Chromium 的关键步骤。我们讨论了使用 Ubuntu 24.04 LTS 操作系统、安装 Git 和 Python 等必要软件，以及配备足够的 RAM 和磁盘空间的重要性。同时，我们强调了稳定高速的网络条件对于下载和同步源代码的影响。
记录一次.gitignore 失效问题
qq_38883889的博客
08-12 209
今天使用git同步同事的代码时，出现一个问题，.gitignore限制失效，导致我本地生成的临时缓存文件被跟踪到了commit中，执行 git rm --cache .后再add commit也不行，很奇怪就研究了一下，下面将我的解决方案分享出来供大家参考。
版本控制基础理论
最新发布
To_be_Designer
08-13 213
所有的版本都存在服务器上，用户的本地只有自己以前所同步的版本。而且所有的数据都保存在单一的服务器上，有很大的风险这个服务器会损坏，这样就会丢失所有的数据，当然可以定期备份，代表产品WSVN,CVS,VSS.所有的版本信息仓库全部同步到本地的每个用户，这样就可以在本地查看所有版本历史，可以离线在本地提交，只需在联网时push到相应的服务器或其他用户那里。由于每个用户那里保存在都是所有的版本数据，只要有一个用户的设备没有问题就可以恢复所有的数据，但这里增加了本地存储的占用。其中HEAD指向最新放入仓库的版本。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值