python 程序的性能分析优化(huffman编码程序性能分析的一个小结论).docx

python程序的性能分析优化(huffman编码程序性能分析的一个小结论)

第一篇：python程序的性能分析优化(huffman编码程序性能分析的一个小结论)python程序的性能分析优化（huffman编码程序性能分析的一个小结论）python程序的性能分析优化（huffman编码程序性能分析的一个小结论）在前面的随笔，关于我写的用python实现huffman,范式huffman的程序进行性能分析。http:///linux/sdk/python/charm-26/在Python中，函数调用代价不菲；除其它因素外，还要花一段时间解决函数参数列表（除了其它的事情外，还要分析位置参数和缺省参数）。初始化框架对象还要采取一些建立步骤（据TimPeters在comp.lang.python上所说，有100多行C语言程序；我自己还没检查Python源代码呢）对于huffman编码的程序而言，处理一个24M的文本，需要逐一处理其中所有的2429218个bytes，以计算所有字符出现的频率。对于一个需要循环2429218的循环而言，调用2429218次file.read(1),和调用2429218/1000次的file.read(1000)在函数调用付出的代价会有很大不同的。这是为什么用file.read(1)速度慢的重要原因。我的程序里面在2429218次循环里分别尝试了使用ifcur==size#size是一个常数ncallstottimepercallcumtimepercallfilename:lineno(function)2429212945.1890.00045.3830.000compressor.py:57(next)44.36444.36489.74789.747huffman.py:94(caculateFrequence)242940.1700.0000.1700.000{method'read'of'file'objects}243100.0240.0000.0240.000{len}对比ifcur==len(buf)#buf是一个stringncallstottimepercallcumtimepercallfilename:lineno(function)2429212965.6680.00086.9770.000compressor.py:57(next)45.23645.236132.212132.212huffman.py:94(caculateFrequence)2431643921.0270.00021.0270.000{len}对比一下就会发现，len(buf)带来的时间代价是不可忽略的，20s呢。下面写了一个关于函数调用多一层调用带来的时间代价的验证小程序。times=24292128deffoo():sum=0foriinrange(10):sum+=1sum=0defuseFoo():foo()10defapp1():globaltimesforiinrange(times):foo()16defapp2():globaltimesforiinrange(times):useFoo()21app1()app2()25运行结果：app2由于多了一层的函数调用，多消耗了将近1分钟的函数调用时间。timepython-mcProfile-stimetestfunc.pyncallstottimepercallcumtimepercallfilename:lineno(function)48584256165.0700.000261.5590.000testfunc.py:2(foo)4858425898.1500.00098.1500.000{range}2429212853.2360.000184.5950.000testfunc.py:8(useFoo)32.63432.634163.862163.862testfunc.py:12(app1)32.25632.256217.485217.485testfunc.py:17(app2)0.0010.001381.348381.348{execfile}0.0000.000381.347381.347testfunc.py:1()0.0000.000381.348381.348:1()0.0000.0000.0000.000{method'disable'of'_lsprof.Profiler'objects}1.回到huffman解码的例子，就需要一次读多个bytes，但是处理时候还是1个一个处理。直接把代码写在循环内部，不用函数调用，这样速度最快读一遍24M文本，计算出每个字符频率。需要8-11sself.infile.seek(0)