
Python异常对代码运行性能的影响实例解析
Python的异常处理能力非常强大,但是用不好也会带来负面的影响。我平时写程序的过程中也喜欢使用异常,虽然采取防御性的方式编码会更好,但是交给异常处理会起到偷懒作用。偶尔会想想异常处理会对性能造成多大的影响,于是今天就试着测试了一下。
Python异常(谷歌开源风格指南)
tip:
允许使用异常, 但必须小心。
定义:
异常是一种跳出代码块的正常控制流来处理错误或者其它异常条件的方式。
优点:
正常操作代码的控制流不会和错误处理代码混在一起. 当某种条件发生时, 它也允许控制流跳过多个框架. 例如, 一步跳出N个嵌套的函数, 而不必继续执行错误的代码。
缺点:
可能会导致让人困惑的控制流. 调用库时容易错过错误情况。
结论:
异常必须遵守特定条件:
像这样触发异常: raise MyException("Error message") 或者 raise MyException . 不要使用两个参数的形式( raise MyException, "Error message" )或者过时的字符串异常( raise "Error message" )。
模块或包应该定义自己的特定域的异常基类, 这个基类应该从内建的Exception类继承. 模块的异常基类应该叫做”Error”。
class Error(Exception):
pass
永远不要使用 except: 语句来捕获所有异常, 也不要捕获 Exception 或者 StandardError , 除非你打算重新触发该异常, 或者你已经在当前线程的最外层(记得还是要打印一条错误消息). 在异常这方面, Python非常宽容, except: 真的会捕获包括Python语法错误在内的任何错误. 使用 except: 很容易隐藏真正的bug。
尽量减少try/except块中的代码量. try块的体积越大, 期望之外的异常就越容易被触发. 这种情况下, try/except块将隐藏真正的错误。
使用finally子句来执行那些无论try块中有没有异常都应该被执行的代码. 这对于清理资源常常很有用, 例如关闭文件。
当捕获异常时, 使用 as 而不要用逗号. 例如
try:
raise Error
except Error as error:
pass
设计实验方式
采取比较简单直观的对照实验。
先定义一个装饰器,用来计算每个函数执行所需时间:
def timer(func):
import time
def wrapper(*args, **kwargs):
startTime = time.time()
f = func(*args, **kwargs)
endTime = time.time()
passTime = endTime - startTime
print "执行函数%s使用了%f秒" % (getattr(func, "__name__"), passTime)
return f
return wrapper
然后用该装饰器装饰测试的函数即可。
再定义一个叫do_something的函数,这个函数中就做一件事,把1赋值给变量a。在每个测试函数中,都会调用这个函数1000000次。
do_something:
def do_something():
a = 1
我根据情况设计了不同的测试组:
测试组1(直接执行耗时操作):
@timer
def test1():
for _ in xrange(1000000):
do_something()
测试组2(耗时操作放在try中执行,不抛出错误):
@timer
def test2():
try:
for _ in xrange(1000000):
do_something()
except Exception:
do_something()
else:
pass
finally:
pass
测试组3(try放耗时操作中,try每一次操作,不抛出错误):
@timer
def test3():
for _ in xrange(1000000):
try:
do_something()
except Exception:
do_something()
else:
pass
finally:
pass
测试组4(try放耗时操作中,try每一次操作并进行异常处理(捕捉抛出的特定异常)):
@timer
def test4():
zero = 0
for _ in xrange(1000000):
try:
if zero == 0:
raise ZeroDivisionError
except ZeroDivisionError:
do_something()
else:
pass
finally:
pass
测试组5(try放耗时操作中,try每一次操作并进行异常处理(捕捉所有异常 try…except BaseException)):
@timer
def test5():
zero = 0
for _ in xrange(1000000):
try:
if zero == 0:
raise ZeroDivisionError
except BaseException:
do_something()
else:
pass
finally:
pass
测试组6(try放耗时操作中,try每一次操作并进行异常处理(捕捉所有异常 不带任何异常类型)):
@timer
def test6():
zero = 0
for _ in xrange(1000000):
try:
if zero == 0:
raise ZeroDivisionError
except:
do_something()
else:
pass
finally:
pass
测试组7(耗时操作放在except中):
@timer
def test7():
zero = 0
try:
if zero == 0:
raise ZeroDivisionError
except ZeroDivisionError:
for _ in xrange(1000000):
do_something()
else:
pass
finally:
pass
测试组8(防御式编码):
@timer
def test8():
zero = 0
for _ in xrange(1000000):
if zero == 0:
do_something()
执行结果
对比结论
通过对比1和2,可以得知直接执行耗时操作和耗时操作放在try中执行并无异常触发时性能消耗几乎是一样的。
通过对比2和7,可以得知使用异常的使用无论是把代码放在 try 中执行还是在 except 中执行性能消耗几乎是一样的。
通过对比2和3,可以得知当不抛出错误时,把try放耗时操作中比耗时操作放在try中性能消耗要略大。
通过对比3和4,可以得知当使用try时无异常抛出跟使用try时抛出异常性能消耗几乎相差好几倍。
通过对比4和5,可以得知try放耗时操作中时,try每一次操作并进行异常处理(捕捉抛出的特定异常)跟try每一次操作并进行异常处理(捕捉所有异常 try…except BaseException)性能消耗几乎是一样的。
通过对比4和8,可以得知使用防御性方式编码比捕捉异常方式性能消耗几乎相差好几倍。
通过对比5和6,可以得知捕捉所有异常(try…except)方式比捕捉所有异常(try…except BaseException)方式要略快。
总结
由以上对比结论,可以总结为:
无论是把代码放在 try 中执行还是在 except 中执行性能消耗几乎是一样的。
直接执行代码与放在try中执行且不抛出异常时性能消耗几乎是一样的,当然理论上try会消耗一点性能,可以忽略不计。
虽然try…except的方式比try…except BaseException和捕捉抛出的特定异常的方式要略快,但扔不建议采取这种方式,因为前者很容易隐藏真正的bug,从而带来严重后果。
通常要采取捕捉抛出的特定异常而不是捕捉所有异常,虽然二者性能消耗几乎一样。
防御性方式编码比捕捉异常方式性能消耗几乎相差好几倍,应尽量采取这种编程方式,提升性能并且更靠谱。
以上就是本文关于Python异常对代码运行性能的影响实例解析的全部内容,希望对大家有所帮助。
数据分析咨询请扫描二维码
若不方便扫码,搜微信号:CDAshujufenxi
Cox 模型时间依赖性检验:原理、方法与实战应用 在生存分析领域,Cox 比例风险模型(Cox Proportional Hazards Model)是分析 “ ...
2025-09-26检测因子类型的影响程度大小:评估标准、实战案例与管控策略 在检测分析领域(如环境监测、食品质量检测、工业产品合规性测试) ...
2025-09-26CDA 数据分析师:以数据库为基石,筑牢数据驱动的 “源头防线” 在数据驱动业务的链条中,“数据从哪里来” 是 CDA(Certified D ...
2025-09-26线性相关点分布的四种基本类型:特征、识别与实战应用 在数据分析与统计学中,“线性相关” 是描述两个数值变量间关联趋势的核心 ...
2025-09-25深度神经网络神经元个数确定指南:从原理到实战的科学路径 在深度神经网络(DNN)的设计中,“神经元个数” 是决定模型性能的关 ...
2025-09-25在企业数字化进程中,不少团队陷入 “指标困境”:仪表盘上堆砌着上百个指标,DAU、转化率、营收等数据实时跳动,却无法回答 “ ...
2025-09-25MySQL 服务器内存碎片:成因、检测与内存持续增长的解决策略 在 MySQL 运维中,“内存持续增长” 是常见且隐蔽的性能隐患 —— ...
2025-09-24人工智能重塑工程质量检测:核心应用、技术路径与实践案例 工程质量检测是保障建筑、市政、交通、水利等基础设施安全的 “最后一 ...
2025-09-24CDA 数据分析师:驾驭通用与场景指标,解锁数据驱动的精准路径 在数据驱动业务的实践中,指标是连接数据与决策的核心载体。但并 ...
2025-09-24在数据驱动的业务迭代中,AB 实验系统(负责验证业务优化效果)与业务系统(负责承载用户交互与核心流程)并非独立存在 —— 前 ...
2025-09-23CDA 业务数据分析:6 步闭环,让数据驱动业务落地 在企业数字化转型中,CDA(Certified Data Analyst)数据分析师的核心价值,并 ...
2025-09-23CDA 数据分析师:以指标为钥,解锁数据驱动价值 在数字化转型的浪潮中,“用数据说话” 已成为企业决策的共识。但数据本身是零散 ...
2025-09-23当 “算法” 成为数据科学、人工智能、业务决策领域的高频词时,一种隐形的认知误区正悄然蔓延 —— 有人将分析结果不佳归咎于 ...
2025-09-22在数据分析、金融计算、工程评估等领域,“平均数” 是描述数据集中趋势最常用的工具之一。但多数人提及 “平均数” 时,默认指 ...
2025-09-22CDA 数据分析师:参数估计助力数据决策的核心力量 在数字化浪潮席卷各行各业的当下,数据已成为驱动业务增长、优化运营效率的核 ...
2025-09-22训练与验证损失骤升:机器学习训练中的异常诊断与解决方案 在机器学习模型训练过程中,“损失曲线” 是反映模型学习状态的核心指 ...
2025-09-19解析 DataHub 与 Kafka:数据生态中两类核心工具的差异与协同 在数字化转型加速的今天,企业对数据的需求已从 “存储” 转向 “ ...
2025-09-19CDA 数据分析师:让统计基本概念成为业务决策的底层逻辑 统计基本概念是商业数据分析的 “基础语言”—— 从描述数据分布的 “均 ...
2025-09-19CDA 数据分析师:表结构数据 “获取 - 加工 - 使用” 全流程的赋能者 表结构数据(如数据库表、Excel 表、CSV 文件)是企业数字 ...
2025-09-19SQL Server 中 CONVERT 函数的日期转换:从基础用法到实战优化 在 SQL Server 的数据处理中,日期格式转换是高频需求 —— 无论 ...
2025-09-18