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所在的目录，故最后输出的Ｃ代码文件不会到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/

 

转载于:https://www.cnblogs.com/jianmu/p/7497274.html