《Code Complete》ch.25 代码调整策略

WHAT?

本章讨论程序性能调整问题。但是对用户来说,程序员按时交付软件,提供一个清爽的用户界面,避免系统经常死机常常比程序性能更加重要

WHY?

在程序设计这种文化中,编写出能够节省几微秒的代码可以证明你很酷--

HOW?

Pareto法则

即80/20法则,指你可以通过20%的努力获取80%的成果

一些无稽之谈

  • 在搞基高级语言中,减少代码行数可以加快代码执行速度
  • 特定运算可能比其他的更快,代码规模也较小:在某个环境下提升程序性能的方法放到另一个环境中可能会损害程序性能。在调整代码的时候你实际上隐含了一个承诺,即你将根据环境变化(包括编译器种类、版本、库版本的改变等)重新进行剖测和调整
  • 应当随时随地进行优化
  • 程序的运行速度同其正确性一样重要:在程序无法正确运行时,不可能去要求程序应当更小巧或运行更快

常见的低效率之源

  • 输入/输出操作:程序效率底下的根源之一就是不必要的输入/输出,优先在内存中处理文件,而不是磁盘、数据库或者网络
  • 分页:引发操作系统缺页中断(page faults)的运算会比在同一页的运算慢很多
  • 系统调用:调用系统子程序的代价是非常可观的,通常涉及系统的上下文切换(context switch)——保存程序状态、恢复内核状态等
  • 解释型语言:慢于编译型语言
  • 错误:比如数据库缺少索引

性能测量

  • 如果没有测量性能变化,那么你想当然的优化结果不过是代码变得更加晦涩难懂
  • 应当用分配给程序的cpu时钟来计算,而不是日期时钟
  • 应当明确测量程序初始化带来的额外系统负担

《Code Complete》ch.25 代码调整策略,布布扣,bubuko.com

时间: 2024-12-25 08:13:10

《Code Complete》ch.25 代码调整策略的相关文章

《Code Complete》ch.26 代码调整技术

WHAT? 提高代码运行速度的方法,减少代码的资源占用 WHY? 这里提出的都是“可以尝试的”方法,有的或许在你的环境根本不起作用,有的则能实实在在产生很好的效果 HOW? Logic - 逻辑 在知道答案后停止判断 按照出现频率来调整判断顺序:让运行最快和判断结果最肯能为真的判断先行,即,让程序更容易进入常见状况的处理 用查询表代替复杂表达式 惰性求值:lazy loading Loop - 循环 将判断外提 合并:将两个相同计数器的循环合并 展开:循环被完全展开后,将具有更快的速度 尽量减少

软件架构————代码调整策略与技术

性能 对用户来说,程序员按是交付软件,提供一个清爽的用户界面,避免系统死机常常比程序的性能更为重要. 性能同代码速度之间存在着很松散的关系.如果只是关注于代码的运行速度,那么这种工作有点顾此失彼.特别要当心放弃其他功能区让代码跑的更快.如果过分强调速度,程序的整体性能常常不升反降. 性能和代码调整 程序需求:在花费时间处理性能问题之前,请想清楚是否在解决一个确实需要解决的问题. 程序设计:程序设计包括了单个程序的主要框架,主要包括程序如何被分解为类.有时程序的设计会使一个高性能的系统难于实现.其

《Code Complete》ch.24 重构

WHAT? 重构(refactoring),Martin Fowler将其定义为“在不改变软件外部行为的前提下,对其内部结构进行改变,使之更容易理解并便于修改”. WHY? 神话:一个管理很完善的软件项目,应该首先以系统化的方法进行需求开发,定义一份严谨的列表来描述程序的功能.设计完全遵循需求,并且完成的相当仔细,这样就让程序员的代码编写工作从头到尾直线型地工作.表明绝大多数代码首次编写后就已完美,测试通过即可被抛诸脑后.代码被修改的惟一时机发生在交付使用后在新版本进行功能的添加 现实:在初始开

《Code Complete》ch.29 集成

WHAT? 集成是这样一种软件开发行为:将一些独立的软件组合为一个完整的系统. WHY? 更容易诊断缺陷 尽早获得一个可工作的产品 更好的顾客关系 增强士气 更可靠地估计进度表 更准确的现状报告 HOW? 集成的两种方式 阶段式集成(爆炸集成) 增量集成(滚雪球集成) 增量集成的策略 自顶向下(Top-Down):使用底层stub类,逐渐替换为实际的类.若底层接口实现起来有bug,或者有性能问题,会导致顶层设计变更 自底向上(Bottom-Up):“让底层细节驱动高层类的设计”违反了信息隐藏原则

《Code Complete》ch.23 调试

WHAT? 调试——发现错误的一种手段 WHY? 相对于不善于调试的程序员,善于调试的程序员只需要前者1/20的时间就可以找出问题所在 HOW? 科学的调试方法 把错误的发生稳定下来:假设-证实/证伪 确定错误原因:二分法 同他人讨论问题 忏悔式调试 抛开问题,休息一下 修正问题 动手之前先要理解问题 理解程序本身,而不仅仅是问题 验证对错误的分析 放松一下 治本,而不是治标 修改代码时一定要有正确的理由:不要随机地修改代码,在没有理解代码时对她做的改动越大,你对她能正确工作的信息就越低 检查自

《Code Complete》ch.11 变量名的力量

What? 如何给变量命名 Why? 易读(你三个月前的代码=别人的代码),易记,恰如其分 整齐的命名具有美感,强迫症患者居家旅行杀人放火之必备 How? 以问题为导向 好名字反映的是问题(what),并非解决方案(how).名字不应体现计算细节 // good Object studentData; int sum; // bad Object inputData; int calcValue; 控制变量名长度 合适的变量名长度为10-16个字符 较长的名字适用于少用到的全局变量,较短的名字适

《Code Complete》ch.8 防御式编程

WHAT? 主要思想:子程序不应因传入参数错误而被破坏 WHY? 保护程序免遭非法输入的破坏 HOW? 断言 assert denominator != 0 : "denominator should not be 0"; // 启动VM时需要 -ea 参数用以启动assert功能 只用于开发.维护阶段 用错误处理代码来处理预期会发生的状况,用断言来处理绝不会发生的状况 避免把需要执行的代码放入断言中 用断言来注解并验证前条件和后条件 错误处理技术 返回中立值(当对返回结果准确性要求较

《Code Complete》ch.7 高质量的子程序

WHAT? 子程序(routines)是为实现一个特定目的而编写的可被调用的方法或过程.在C++中是函数(function),在Java中是方法(method),在VB中是函数过程(function procedure)或子过程(sub procedure). WHY? 降低复杂度 引入中间.易懂的抽象 避免代码重复 支持继承.重写 隐藏实现细节 提高可移植性 改善性能(对明确的子程序进行优化) HOW? 内聚性(cohesion):是指子程序中各种操作之间联系的紧密程度 编程的目标是让每一个子

《Code Complete》ch.20 软件质量概述

WHAT & WHY ? 软件质量的特性 外在特性 正确性(Correctness) 可用性(Usability) 效率(Efficiency) 可靠性(Reliability) 完整性(Integrity) 适应性(Adaptability) 精确性(Accuracy) 健壮性(Robustness) 内在特性 可维护性(Maintainability) 灵活性(Flexibility) 可移植性(Portability) 可重用性(Reusability) 可读性(Readability)