当前位置: 首页 > news >正文

c程序杂谈系列(职责链模式与if_else)

从处理器的角度来说,条件分支会导致指令流水线的中断,所以控制语句需要严格保存状态,因为处理器是很难直接进行逻辑判断的,有可能它会执行一段时间,发现出错后再返回,也有可能通过延时等手段完成控制流的正确性。所以笔者在想,使用过多的if _else,除了可读性差,是否还会对执行效率造成影响呢?

于是笔者决定采用职责链重构if控制语句,笔者猜想,如果采用设计模式既可以避免if分支,提高执行效率,同时可以让程序具备解耦合性和可维护性,是否是一种更优解呢?

为了验证笔者的猜想,更好的优化c语言程序,笔者使用职责链模式对一段if_else程序进行了重构。

程序的性能标准是执行时间,计算程序时间的程序来源于:C语言 计算程序运行时间(精确到毫秒/微秒)_c语言计算运行时间-CSDN博客

以下是笔者本人用c编写的责任链设计模式:

#include<stdio.h>
#include<stdlib.h>
#include<memory.h>
#include<string.h>
#include <windows.h>typedef int (*Handler)(int);typedef struct task_node
{Handler handler;struct task_node* next;
}taskN;int task1(int a) {if (a == 1) {//printf("a == 1"); printf会耗费大量时间,为了不影响测试,所以只留下判断语句return 0;}return -1;
}int task2(int a) {if (a == 2) {return 0;}return -1;
}int task3(int a) {if (a == 3) {return 0;}return -1;
}int task4(int a) {if (a == 4) {return 0;}return -1;
}int task5(int a) {if (a == 5) {return 0;}return -1;
}int task6(int a) {if (a == 6) {return 0;}return -1;
}int task7(int a) {if (a == 7) {return 0;}return -1;
}int task8(int a) {if (a == 8) {return 0;}return -1;
}int task9(int a) {if (a == 9) {return 0;}return -1;
}int task10(int a) {if (a == 10) {return 0;}return -1;
}int task11(int a) {if (a == 11) {return 0;}return -1;
}int task12(int a) {if (a == 12) {return 0;}return -1;
}taskN* initi() {taskN* tas1 = malloc(sizeof(taskN));taskN* tas2 = malloc(sizeof(taskN));taskN* tas3 = malloc(sizeof(taskN));taskN* tas4 = malloc(sizeof(taskN));taskN* tas5 = malloc(sizeof(taskN));taskN* tas6 = malloc(sizeof(taskN));taskN* tas7 = malloc(sizeof(taskN));taskN* tas8 = malloc(sizeof(taskN));taskN* tas9 = malloc(sizeof(taskN));taskN* tas10 = malloc(sizeof(taskN));taskN* tas11= malloc(sizeof(taskN));taskN* tas12= malloc(sizeof(taskN));tas1->handler = task1;tas2->handler = task2;tas3->handler = task3;tas4->handler = task4;tas5->handler = task5;tas6->handler = task6;tas7->handler = task7;tas8->handler = task8;tas9->handler = task9;tas10->handler = task10;tas11->handler = task11;tas12->handler = task12;tas1->next = tas2;tas2->next = tas3;tas3->next = tas4;tas4->next = tas5;tas5->next = tas6;tas6->next = tas7;tas7->next = tas8;tas8->next = tas9;tas9->next = tas10;tas10->next = tas11;tas11->next = tas12;return tas1;}void process(taskN* bol, int a) {int i = bol->handler(a);while (i != 0){i = bol->handler(a);bol = bol->next;}
}void main() {double run_time;LARGE_INTEGER time_start;	//开始时间LARGE_INTEGER time_over;	//结束时间double dqFreq;		//计时器频率LARGE_INTEGER f;	//计时器频率QueryPerformanceFrequency(&f);dqFreq = (double)f.QuadPart;QueryPerformanceCounter(&time_start);taskN* bol = initi();int a = 12;for (int i = 0; i <= 50000000; i++){/*if (a == 1) {}else if (a == 2) {}else if (a == 3) {}else if (a == 4) {}else if (a == 5) {}else if (a == 6) {}else if (a == 7) {}else if (a == 8) {}else if (a == 9) {}else if (a == 10) {}else if (a == 11) {}else if (a == 12) {}else {}*//*process(bol, a);*/switch (a) {case 1:break;case 2:break;case 3:break;case 4:break;case 5:break;case 6:break;case 7:break;case 8:break;case 9:break;case 10:break;case 11:break;case 12:break;default:break;}}QueryPerformanceCounter(&time_over);	//计时结束run_time = 1000000 * (time_over.QuadPart - time_start.QuadPart) / dqFreq;//乘以1000000把单位由秒化为微秒,精度为1000 000/(cpu主频)微秒printf("\nrun_time:%fus\n", run_time);/*为了偷懒,程序就懒得free了*/}

使用if_else时:

a=1,第一个循环执行:

a=12,最后一个循环执行:

两者时间基本没区别,在循环语句中

笔者还测试了只有if( a== 1)这一个判断语句下的性能:

可以看出基本没什么区别。

使用case时:

a=12时如下,与a=1时的结果几乎没有区别:

switch语句除了比较简洁一点,执行速度完全没法比。

 使用责任链时:

任务优先级在责任链上过高(a=1):

 任务优先级在责任链过低(a=12):

可以看出,职责链的速度非常慢,特别是任务优先级低时,执行速度几乎是if_else的150倍。

综上得出,if_else的执行速度是最快的,如果判断的时间复杂度过大,而且判断语句的数量较少,使用if_else,性能可能会更好。

但是,上述的前提是建立在判断语句的数量较少的情况下。

现在让我们考虑这样一种情况:不是判断a从1到12,而是从a到10000呢?程序等价于下图:

再附加一个条件,大多数情况下,a的值都是1。

虽然if_else的耗时比较短,但是在大量的循环下,耗时也不容小觑。因为a大多数情况是1,其他的判断分支只有小概率发生,此时我们使用责任链就可以完美跳过这些语句的判断:

(程序用for循环表示中间的分支,写得不准确,理解意思就好)

当然,读者可能认为if else if在这里也可以跳过中间的语句,也能实现优先级,但是如果改成这样呢:

这种情况下,if else if只能执行其中一个,显然不行,使用大量的if,就变成了上面的情况,我们不得不将原先的代码大量删除并重写,这十分让人难受。这样一对比,对于部分实现的if分支,使用责任链的优点有什么呢?如下图:

在责任链任务里进行改动,可以选择责任链终止的位置,跳过后面的任务,当然,通过goto等跳转指令也是可以实现的,但是if语句很难做到这样灵活,对于复杂的业务场景,很难在原先的基础上进行拓展,责任链的解耦合性和可拓展性是非常好的优点。

考虑复杂的业务场景,责任链明显优于传统的if_else。

尽管如此,if_else还是十分友好的,特别是在mcu等产品的开发中,使用设计模式的资源花费简直是奢求,毕竟设计模式是针对高级语言的,大多数情况下if_else往往是最优解。不过,笔者认为大量使用if_else的前提是项目不需要长期维护,一般情况下还是要多使用设计模式,例如在linux内核中就有源码使用了责任链模式,这是从性能,解耦合性和可读性等多方面考虑,值得开发者学习。如果是小型项目,对维护没有要求,而且控制语句的数量较少,为了性能和简便性可以考虑直接使用if_else分支。但是如果大型项目中含有大量if分支,可以考虑使用设计模式重构。

相关文章:

  • 北京网站建设多少钱?
  • 辽宁网页制作哪家好_网站建设
  • 高端品牌网站建设_汉中网站制作
  • Spring中使用到的设计模式及其源码分析
  • [红明谷CTF 2021]write_shell 1
  • UE5+OpenCV配置(Windows11系统)
  • Java从基础到高级特性及应用
  • 001.精读《Big Data: A Survey》
  • SVD用于图形处理★★★
  • element ui 修改table筛选按钮为自定义按钮
  • C# Parallel设置最大并发度
  • 【Qwen-Audio部署实战】Qwen-Audio-Chat模型之FastApi部署实战
  • Fréchet Inception Distance(FID)图像生成技术指标
  • 《AM-Bi-LSTM: Adaptive Multi-Modal Bi-LSTM for Sequential Recommendation》
  • MATLAB学习日志DAY23
  • Java | Leetcode Java题解之第283题移动零
  • Git操作指令(已完结)
  • DolphinScheduler学习
  • 【附node操作实例】redis简明入门系列—字符串类型
  • Android优雅地处理按钮重复点击
  • Fundebug计费标准解释:事件数是如何定义的?
  • Linux各目录及每个目录的详细介绍
  • supervisor 永不挂掉的进程 安装以及使用
  • 闭包--闭包作用之保存(一)
  • 从伪并行的 Python 多线程说起
  • 大主子表关联的性能优化方法
  • 仿天猫超市收藏抛物线动画工具库
  • 猫头鹰的深夜翻译:Java 2D Graphics, 简单的仿射变换
  • 小试R空间处理新库sf
  • 译有关态射的一切
  • 用jQuery怎么做到前后端分离
  • 用Node EJS写一个爬虫脚本每天定时给心爱的她发一封暖心邮件
  • ​520就是要宠粉,你的心头书我买单
  • ​决定德拉瓦州地区版图的关键历史事件
  • ​虚拟化系列介绍(十)
  • # Apache SeaTunnel 究竟是什么?
  • # C++之functional库用法整理
  • # 深度解析 Socket 与 WebSocket:原理、区别与应用
  • ## 1.3.Git命令
  • (k8s)kubernetes集群基于Containerd部署
  • (PHP)设置修改 Apache 文件根目录 (Document Root)(转帖)
  • (pojstep1.1.1)poj 1298(直叙式模拟)
  • (附源码)springboot猪场管理系统 毕业设计 160901
  • (附源码)计算机毕业设计SSM基于健身房管理系统
  • (实战篇)如何缓存数据
  • (四)软件性能测试
  • (一)80c52学习之旅-起始篇
  • (自适应手机端)响应式新闻博客知识类pbootcms网站模板 自媒体运营博客网站源码下载
  • (自用)网络编程
  • **登录+JWT+异常处理+拦截器+ThreadLocal-开发思想与代码实现**
  • *算法训练(leetcode)第四十五天 | 101. 孤岛的总面积、102. 沉没孤岛、103. 水流问题、104. 建造最大岛屿
  • .NET Core中的去虚
  • .net framework profiles /.net framework 配置
  • .Net IOC框架入门之一 Unity
  • .NET NPOI导出Excel详解
  • .Net 垃圾回收机制原理(二)
  • .NET(C#、VB)APP开发——Smobiler平台控件介绍:Bluetooth组件
  • .NET与java的MVC模式(2):struts2核心工作流程与原理