?Protocol Buffers （類似XML的一種數(shù)據(jù)描述語言）最新版本2.3里，protoc―py_out命令只生成原生的Python代碼。 盡管PB（Protocol Buffers）可以為C++語言生成快速解析和序列化代碼，但是這種方式對(duì)于Python不適用，并且手動(dòng)生成的已包裝的代碼需要非常大的維護(hù)工作。在討論組里，這是一個(gè)常見的功能要求，由于一個(gè)必備的客戶端組件―AppEngine（根據(jù)團(tuán)隊(duì)介紹名稱為AppEngine），生成原生的Python代碼有更高的優(yōu)先級(jí)。

幸運(yùn)的是， PB 2.4版本中本地化代碼已被提名，在 svn的分支中已經(jīng)可以下載，因此你能夠使用快速的 PB有一段時(shí)間了。 （我們使用 r352版本有一段時(shí)間了，還沒有遇到任何問題。） PB團(tuán)隊(duì)一直不愿輕易指定任何發(fā)布日期，在我的威脅下， Kenton Varda提到日期初步定在 2011年初。

我沒有在其它地方看見過這個(gè)文檔，希望它能對(duì)其他人有所幫助.

如何做能讓它快起來

安裝好新的PB庫之后并使用 protoc --py_out=...? 重新構(gòu)建好你的PB之后，你需要在運(yùn)行你的Python程序之前進(jìn)行環(huán)境變量 PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp 的設(shè)置，以便于選擇C++的，或者PB默認(rèn)使用的Python實(shí)現(xiàn).

就這樣了！這至少就能在可以動(dòng)態(tài)轉(zhuǎn)化/序列化消息的PB運(yùn)行時(shí)庫用通用的C++代碼了. (注意我們還沒有生成任何C++代碼.)

它能有多快呢? 我編寫了一個(gè)簡單的程序來獲得性能在我們的應(yīng)用程序中的提升感觀:
?

            
nruns = 1000nwarmups = 100xs = ... # your protobufsdef ser(): return [x.SerializeToString() for x in xs]def parse(ys): for y in ys: pb.Email().ParseFromString(y)
 
t = timeit.Timer(lambda:None)
t.timeit(nwarmups)print 'noop:', t.timeit(nruns) / nruns
 
t = timeit.Timer(ser)
t.timeit(nwarmups)print 'ser:', t.timeit(nruns) / nruns / len(xs)
 
ys = ser()
t = timeit.Timer(lambda: parse(ys))
t.timeit(nwarmups)print 'parse:', t.timeit(nruns) / nruns / len(xs)print 'msg size:', sum(len(y) for y in ys) / len(ys)

          

以秒為單位，這段程序在我的桌面上給出了如下幾個(gè)時(shí)間結(jié)果:
?

            
$ python sandbox/pbbench.py out.ini
ser: 0.000434461673101
parse: 0.000602062404156
msg size: 10730
 
$ PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp \
> python sandbox/pbbench.py out.ini
ser: 2.86788344383e-05
parse: 7.63910810153e-05
msg size: 10730

          

這顯示出在序列化和轉(zhuǎn)化方面分別有15和8被的速度提升。不壞！但還可以更快.

如何做讓它更快

現(xiàn)在我們實(shí)際上只是特地針對(duì)你的PB生成了一個(gè)C++實(shí)現(xiàn)，而我們從來沒有使用過運(yùn)行時(shí)反射。首先，為你的Python項(xiàng)目添加一個(gè)C擴(kuò)展，不如，通過修改如下的 setup.py:
?

            
setup(
  ...
  ext_modules=[Extension('podpb',
sources=['cpp/podpb.c','cpp/main.pb.cc'], libraries=['protobuf'])],
  ...
  )

          

使用 protoc --cpp_out=cpp 生成main.pb.c, 并按如下所示創(chuàng)建 podpb.c 來設(shè)置一個(gè)空的 Python C 模塊:
?

            
#include 
            
              
 
static PyMethodDef PodMethods[] = {
 {NULL, NULL, 0, NULL}    /* Sentinel */};
 
PyMODINIT_FUNC
initpodpb(void)
{
 PyObject *m;
 
 m = Py_InitModule("podpb", PodMethods); if (m == NULL)  return;
}

            
          

現(xiàn)在就運(yùn)行 python setup.py build 命令會(huì)構(gòu)建所有的東西. 只要將C模塊（在這里是podpb）導(dǎo)入到你的項(xiàng)目中，PB 運(yùn)行時(shí)庫就將會(huì)自動(dòng)使用 C++ 實(shí)現(xiàn)了.

現(xiàn)在我們就分別有了68倍x 和 13倍 的速度提升. 吼吼.
?

            
$ PYTHONPATH=build/lib.linux-x86_64-2.6/:$PYTHONPATH \
> PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp \
> python sandbox/pbbench.py out.ini
ser: 6.39575719833e-06
parse: 4.55250144005e-05
msg size: 10730

          

我這篇文章發(fā)布到很多地方，大事完全忘了它的存在。同時(shí) connex.io 和 Greplin 發(fā)布了他們的原生的 Python實(shí)現(xiàn)，cypb和fast-python-pb。cypb在PB的郵件列表中公布過，可以運(yùn)行，但仍需要提升到可用的狀態(tài)。fast-python-pb目前只支持string int32, int64 雙精度浮點(diǎn)和子消息成員。除了這些項(xiàng)目，其他的我都不了解。你也可以查看我的orginal thread PB郵列表來了解到這些。