Cython的用法以及填坑姿势

因为项目需要,需要优化已有的Python代码。目前Python代码的执行过程是将Python代码转变成一行行指令,然后解释器解释指令的执行,调用到C代码层。如果去掉指令解释这个阶段,直接进入C代码层,效率就比较高了。如果用之前所述的使用Python C API将Python代码改造为C代码并作为Python的内建模块,工作量极其大,也不能保证其正确性,所以这种方法不太现实。而Cython库正好符合这种场景需求,将已有的Python代码转化为C语言的代码,并作为Python的built-in模块扩展。

版本说明:

Python 2.7.13  (CPython)

Cython 0.25.2

Python的文件类型介绍:

.py       python的源代码文件

.pyc     Python源代码import后,编译生成的字节码

.pyo     Python源代码编译优化生成的字节码。pyo比pyc并没有优化多少,只是去掉了断言

.pyd     Python的动态链接库(Windows平台)

.py, .pyc, .pyo 运行速度几乎无差别,只是pyc, pyo文件加载的速度更快,不能用文本编辑器查看内容,反编译不太容易

 

本文的目标是将test.py文件生成test.c文件,然后将test.c文件作为Python源码的一部分,重新编译生成Python,使用时直接import test即可使用test模块。

Cython基本介绍:

文档中这样总结Cython:

Cython is an optimising static compiler for both the Python programming language and the extended Cython programming language (based on Pyrex). It makes writing C extensions for Python as easy as Python itself.

是一个Python编程语言的编译器,写C扩展就像写Python代码一样容易。

其最重要的功能是:

  • write Python code that calls back and forth from and to C or C++ code natively at any point.

即 将Python代码翻译为C代码。之后就可以像前面文章介绍的C语言扩展Python模块使用这些C代码了。

 

Cython基本用法:

 在使用Cython编译Python代码时,务必要安装C/C++编译器,本文是直接安装了Visiual Studio 2015的开发环境。

1. 安装Cython库

   pip install Cython

 就是如此简单明了

2. 编写一个测试代码文件test.py放在D:/test/test.py

def say_hello():
    print "hello world"

然后在同一目录下,新建一个setup.py文件,内容如下:

from distutils.core import setup
from Cython.Build import cythonize

setup(ext_modules = cythonize("test.py"))

cythonize()是Cython提供将Python代码转换成C代码的API,

setup是Python提供的一种发布Python模块的方法。

3. 使用命令行编译Python代码:

python setup.py build_ext  --inplace

如果出现这种情况是因为没有C编译器相关的配置没有设置好,在Windows上一般采用Microsoft VisualStudio,不同的VS版本设置不同。

  • Visual Studio 2010 (VS10): SET VS90COMNTOOLS=%VS100COMNTOOLS%
  • Visual Studio 2012 (VS11): SET VS90COMNTOOLS=%VS110COMNTOOLS%
  • Visual Studio 2013 (VS12): SET VS90COMNTOOLS=%VS120COMNTOOLS%
  • Visual Studio 2015 (VS14): SET VS90COMNTOOLS=%VS140COMNTOOLS%
  • Visual Studio 2017 (VS14): SET VS90COMNTOOLS=%VS150COMNTOOLS% 

这里采用VS2015作为C的编译器。

在命令行中输入SET VS90COMNTOOLS=%VS140COMNTOOLS%

然后输入编译命令:python setup.py build_ext --inplace

最终的生成结果如下:

在D:/test/ 目录中:

test.c是test.py转化后的C代码文件,可以看到test.c非常大!!

test.pyd是python的动态链接库,我们在使用import test时会加载

build目录编译过程中生成的临时文件

使用刚刚生成的test模块,就像使用Python的任意模块一样:

 

这里稍微解释一下 命令行:python setup.py build_ext --inplace

build_ext是指明python生成C/C++的扩展模块(build C/C++ extensions (compile/link to build directory))

--inplace指示 将编译后的扩展模块直接放在与test.py同级的目录中。

 

整个Cython工作的流程如下图所示:

分两步:

1).py文件使用Cython被编译为.c文件;

2).c文件使用C编译器生成.pyd(windos)或.so(linux)文件。

 除了这种普遍的用法外,还可以在Python代码的某些地方加上静态类型声明,也可以更进一步提升Python的运行效率,这些属于小技巧了~

比如:

def say_hello(int s):
    cdef int a = 2
    print s + 2

s和a变量直接指示为int类型,不用再做动态语言的类型推断了。

 

小测试:

import math
import time

def f():
    time1 = time.time()
    for i in range(100000000):
        x = math.sqrt(i)
    time2 = time.time()
    print time2 - time1

这段原生的Python代码运行时间是13.17秒,使用Cython优化后,运行时间为9.36秒。基本上提升30%。其实Cython一般对外声称的效率提升也大概是这么多。

 

Cython中的坑

在这一小节中,讨论Cython中的一些坑以及填坑姿势。Cython官方文档中已经明确指出一些不支持的Python特性,有些不打算修复,再结合具体项目场景,给出一些坑的解决方案。

具体项目需求: 将一些需要优化的Python代码模块翻译成C代码,加入项目中,编译链接之后,作为Python的一个built-in模块。

所以,只需要转换成C代码这一步骤即可,不需要使用Python提供的distutils模块,只需要Cython提供的cythonize。

1. 从Python的site-package中提取install的Cython目录,独立出来。因为是供给其他人使用,其他人pip install cython的话可能版本不一致,会出现一些问题。

Cython目录是Cython源码以及Python2.7/Lib/site-package下的cython.py,即:

CythonTool是封装了转化为C代码的py脚本文件。

在使用时,需要设置一下sys.path,在import时才能找到我们独立出来的Cython模块。

# import Cython path
sys.path.insert(0, cython_path) from Cython.Build import cythonize from Cython.Compiler import Options

在sys.path的头部添加cython_path,所以Python site-package里的Cython就不会影响我们独立出来的Cython模块。

2. 在编译python代码为C代码时,需要指定输出的C代码文件路径,Cython默认的是python脚本目录,这样会导致py文件与.c文件混在一起,很容易就乱了。

目前工作目录有三个

LibDir:  需要优化的Python脚本所在目录

CfileDir: 输出的C代码文件所在的目录

ToolDir:  封装的cython优化脚本所在的目录,其作用是将LibDir中的Python模块转换为C代码,然后输出到CfileDir

故而封装的cython脚本工作目录在ToolDir,脚本中最核心的是代码是:

cythonize(pyfilePath, build_dir=CfileDir)

使用build_dir参数指明C代码输出目录。

看起来很完美,但是Cython源码在这里里有个坑。

当指定build_dir时,当pyfilePath与CfileDir都为绝对路径时,且cython脚本的工作目录与pyfilePath不一致时,cythonize会将输出文件的目录置为pyfilePath所在的目录,故最后输出的C代码文件不会到CfileDir里。

所以应该在封装的cython脚本里调用os.chdir(LibDir),转换完成时再切换到原有工作目录。牢记cython的工作目录应该与待优化的python脚本目录一致。

原因:cythonize中的实现有这样一段代码:【调试状态下】

 

红色框中,如果c_file是一个绝对文件名时,会出现以下情况,至于c_file为什么会是一个绝对的文件名,是因为cython的工作目录与待优化脚本目录不匹配导致的。

 

 3. 原始的Cython对Python的Package支持度不够,一个大坑!!

只能通过修改Cython的源码来填坑。

原始的Cython编译Python之后,生成的C代码里有两个关键的地方,拿test模块为例:

这里定义了test模块初始化函数,这个函数里会有创建test模块的代码部分:

当import时,Python解释器会调用这里,初始化test模块,将test名字加入到sys.builtin_module_names中。

测试发现,如果有D:/Lib/mypackate/test.py , 编译后,生成的C代码与D:/Lib/test.py生成的代码并无不同,即mypackate这个包被忽略了,导致生成的C代码没有了包依赖关系。

顺着代码阅读,最终确定了问题出现的源头,Cython/Compiler/ModuleNode.py, 修改了此文件中的两个函数:

1)生成模块init代码函数:full_module_name替换掉env.module_name, 即用initmypackage_test替换init_test

2) 修改了创建模块时传入的模块名规则,并考虑到mypackage/__init__.py这种情况, 对于package来说需要加入__path__用以标识这个对象不是普通的Python模块,而是一个包。

 

 4.  深坑。 inspect、types相关。

Inspect模块中有各种类型判断函数,比如 isfunction, ismethod, ismodule等。这里的坑是:

cython化的函数类型变为了cython_function_or_method,而原始python的函数类型是function,所以如果待优化的Python脚本中使用isfunction(func, types.FunctionType)时,如果func是原始的函数则返回True,而cython化的函数返回False. 除了function类型外还有generator, functionType.func_globals类型也存在不一致。

目前在inspect.py的isfunction中加入了trick,会判断

type(func).__name__=="cython_function_or_method". 并且types.py模块不被cython化,那么如果调用inspect.isfunction(func, types.FunctionType)对于原始的Python函数还是cython化的函数都没有问题了。

但是如果直接使用isinstance(func, types.FunctionType)仍然会存在问题,types.FunctionType只对原始的python函数判断正确。

比较绕,总而言之一句话,python里的类型和cython化后的对应的类型可能会不同。我总结了大部分python类型,其中有几个cython化后类型不一致:

没有什么太好的解决办法,要么改写inspect模块,但还要保证Python代码不能直接使用types模块,要么修改Python源码中关于isinstance的实现。

5. 官方文档中列出的坑

1) 不支持Nested tuple, Python2中的特性,Python3不支持了。所以Cython直接不支持Nested tuple特性

2)找不到变量名:You can disable the latter behaviour by setting "error_on_unknown_names" to

 解决办法:

3)Stack Frames. 

 Cython不支持Stack Frame。

 

总结:可以考虑使用Cython优化一些简单的Python项目,如果用到非常复杂的场景的话,有些语法的特性不支持,会有绕不过去的坑

 

参考资料:

https://github.com/cython/cython

https://mdqinc.com/blog/2011/08/statically-linking-python-with-cython-generated-modules-and-packages/

 

posted @ 2017-09-09 13:50 建木 阅读(...) 评论(...) 编辑 收藏