msgpack[C++]使用笔记 和 msgpack/cPickle性能对比

python版本msgpack安装:

wget http://pypi.python.org/packages/source/m/msgpack-python/msgpack-python-0.1.9.tar.gz

python2.x setup.py install --prefix=/usr/local/similarlib/

python版本的msgpack灰常好用,速度上比python内置的pickle和cpickle都要快一些,C++版本的使用比较麻烦,下面是本人学习时的一个demo,解析python-msgpack dump的一个复杂字典。

[cpp] view plaincopy

  1. #include <msgpack.hpp>  
  2.   
  3. #include <fstream>  
  4. #include <iostream>  
  5. using namespace std;  
  6.   
  7. template <class T>  
  8. void msgunpack(const char* binary_file, T& t, char* buff, uint32_t max){  
  9.     msgpack::unpacked msg;  
  10.     ifstream tf_file(binary_file,ios::in|ios::binary|ios::ate);  
  11.     uint32_t size = tf_file.tellg();  
  12.     tf_file.seekg(0, ios::beg);  
  13.     tf_file.read(buff, size);  
  14.     tf_file.close();  
  15.     msgpack::unpack(&msg, buff, size);  
  16.     msg.get().convert(&t);  
  17. }  
  18.   
  19.   
  20. typedef map<uint32_t, uint32_t> WordsMap;  
  21. typedef map<uint32_t, WordsMap> FieldsMap;  
  22. typedef map<uint64_t, FieldsMap> DocsMap;  
  23.   
  24. int main(int argc, char** argv)  
  25. {  
  26.     uint32_t MAX_BUFF = 1024*1024*100; //100MB  
  27.     char* BUFF = new char[MAX_BUFF];  
  28.   
  29.     DocsMap docsMap;  
  30.     msgpack::unpacked msg;  
  31.     msgunpack("/data/wikidoc/tf_dict_for_nodes/1-1000", docsMap, BUFF, MAX_BUFF);  
  32.     //        msg.get().convert(&docsMap);  
  33.     cout << docsMap.size() << endl;  
  34.         delete[] BUFF;  
  35. }  

参考: http://wiki.msgpack.org/pages/viewpage.action?pageId=1081387#QuickStartforC%2B%2B-ImplementationStatus

下面是本人自己封装的一个msgpack接口头文件mymsgpack.h

[cpp] view plaincopy

  1.  #ifndef MY_MSGPACK_H  
  2.   
  3. #ifndef MY_MSGPACK_H  
  4. #define MY_MSGPACK_H  
  5. #include <fstream>  
  6. #include <msgpack.hpp>  
  7. using namespace std;  
  8.   
  9. template <class T>  
  10. void load_from_file(const char* binary_file, T& t) {  
  11.         ifstream binaryFstream(binary_file,ios::in|ios::binary|ios::ate);  
  12.         uint32_t size = binaryFstream.tellg();  
  13.         char* buff = new char[size];  
  14.         binaryFstream.seekg(0, ios::beg);  
  15.         binaryFstream.read(buff, size);  
  16.         binaryFstream.close();  
  17.         msgpack::unpacked msg;  
  18.         msgpack::unpack(&msg, buff, size);  
  19.         msg.get().convert(&t);  
  20.         delete[] buff;  
  21. }  
  22.   
  23. template <class T>  
  24. void load_from_str(const char* binary_str, int len, T& t) {  
  25.         msgpack::unpacked msg;  
  26.         msgpack::unpack(&msg, binary_str, len);  
  27.         msg.get().convert(&t);  
  28. }  
  29.   
  30. template <class T>  
  31. void dump_to_file(T& t, const char* dump_file) {  
  32.     msgpack::sbuffer sbuf;  
  33.     msgpack::pack(sbuf, t);  
  34.     ofstream dumpFstream(dump_file, ios::out|ios::binary|ios::trunc);  
  35.     dumpFstream.write(sbuf.data(), sbuf.size());  
  36.     dumpFstream.close();  
  37. }  
  38.   
  39. template <class T>  
  40. void dump_to_str(T& t, char** dump_str, int& len) { //外部释放*dump_str  
  41.     msgpack::sbuffer sbuf;  
  42.     msgpack::pack(sbuf, t);  
  43.     len = sbuf.size();  
  44.     *dump_str = (char*)malloc(sbuf.size());  
  45.     memcpy(*dump_str, sbuf.data(), sbuf.size());  
  46. }  
  47.   
  48. #endif  

 

msgpack编译通过,链接不上的问题 undefined reference to `__sync_sub_and_fetch_4'

在x84_64机器上正常,在32bit机器上出现上述问题

[plain] view plaincopy

  1. [xudongsong@BigServerU-4 msgpack-0.5.7]$ cat /etc/issue  
  2. CentOS release 5.4 (Final)  
  3. Kernel \r on an \m  
  4.   
  5. [xudongsong@BigServerU-4 msgpack-0.5.7]$ file /sbin/init  
  6. /sbin/init: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped  

./configure不报错,但是查看config.log显示有错误,程序链接msgpack的库时也报错

原因:gcc不能识别CPU体系,需要手动指明

[plain] view plaincopy

  1. [xudongsong@BigServerU-4 msgpack-0.5.7]$ CFLAGS="-march=pentium -mtune=pentium" ./configure --prefix=/home/xudongsong/msgpack_static --enable-static=yes --enable-shared=no  

make, make install

[xudongsong@BigServerU-4 jobs]$ g++ job_calc_weight.cpp -o job_calc_weight -I/home/xudongsong/msgpack_static/include/ -L/home/xudongsong/msgpack_static/lib/ -lmsgpack

通过!

 

 

下面是msgpack和cPickle进行性能pk的demo程序(不比较pickle,是因为它比cPickle更慢,《Python cook book》里面有说明):

[python] view plaincopy

  1. mport sys,time,msgpack,pickle,cPickle,random  
  2.   
  3. test_list = []  
  4. i = 0  
  5. while i<100000:  
  6.     test_list = random.randrange(1,100000)  
  7.     i += 1  
  8.   
  9. print "common len(serialize) = %s"%len(cPickle.dumps(test_list,0))  
  10. print "compress len(serialize) = %s"%len(cPickle.dumps(test_list,1))  
  11.   
  12. #------------------------------------------------------------------------  
  13. results = {}  
  14. time_start = time.time()  
  15. for i in range(1,1000000):  
  16.         results[i] = cPickle.dumps(test_list,1)  
  17. time_mid_1 = time.time()  
  18. print "cPickle dumps eats %s s"%str(time_mid_1-time_start)  
  19.   
  20. for i in range(1,1000000):  
  21.     cPickle.loads(results[i])  
  22. time_mid_2 = time.time()  
  23. print "cPickle loads eats %s s"%str(time_mid_2-time_mid_1)  
  24.   
  25. #------------------------------------------------------------------------  
  26. results = {}  
  27. time_start = time.time()  
  28. for i in range(1,1000000):  
  29.     results[i] = msgpack.dumps(test_list)  
  30. time_mid_1 = time.time()  
  31. print "msgpack pack eats %s s"%str(time_mid_1-time_start)  
  32.   
  33. for i in range(1,1000000):  
  34.     msgpack.loads(results[i])  
  35. time_mid_2 = time.time()  
  36. print "msgpack unpack eats %s s"%str(time_mid_2-time_mid_1)  
时间: 2024-09-19 08:20:04

msgpack[C++]使用笔记 和 msgpack/cPickle性能对比的相关文章

PHP5.5四种序列化性能对比

json_encode,serialize,igbinary,msgpack四种序列化方式,在之前已经有过相关的测试,PHP5.5这方面的测试暂时没有,这次测试基于PHP5.5,并且测试用例,http://blog.csdn.net/hguisu/article/details/7651730的测试用例是一样的,只是从这个测试上家里igbinary serialize的测试,作为对比,可以参考http://www.ooso.net/archives/538 运行环境        PHP5.5

四种整数数据类型的性能对比

数据|数据类型|性能 在我们写VBA程序的时候,我们经常要面对数据类型定义的选择,有的情况下,业务本身对于数据类型有要求和限制,那么我们并不难以选择,有些时候却没有限制,我们可以任意选用四种整数类型(Byte,Integer,Long,Currency)中的一种,例如: For i=1 to 100 在这行代码中,我们该把变量i定义为什么类型的变量呢?显然四种整数类型都可以正常运行,但是他们的效率是否相同呢?我们到底该如何选择?有的人说,当时是选最小的数据类型Byte,有的人说在32位系统上,3

HBase在单Column和多Column情况下批量Put的性能对比分析

针对HBase在单column family单column qualifier和单column family多column qualifier两种场景下,分别批量Put写入时的性能对比情况,下面是结合HBase的源码来简单分析解释这一现象. 1. 测试结果 在客户端批量写入时,单列族单列模式和单列族多列模式的TPS和RPC次数相差很大,以客户端10个线程,开启WAL的两种模式下的测试数据为例, 单列族单列模式下TPS能够达到12403.87,实际RPC次数为53次: 单列族多列模式下,TPS只有

Hadoop虚拟化的性能对比和调优经验

虚拟化为Hadoop注入了前所未有的活力,从IT生产管理的角度,表现为以下几点: ·Hadoop和其他消耗不同类型资源的应用一起部署共享数据中心可以提高总体资源利用率: ·灵活的虚拟机操作使得用户可以动态的根据数据中心资源创建.扩展自己的Hadoop集群,也可以缩小当前集群.释放资源支持其他应用如果需要: ·通过与虚拟化架构提供的HA.FT集成,避免了传统Hadoop集群中的单点失败,再加之Hadoop本身的数据可靠性,为企业大数据应用提供了可靠保证. 基于这些原因,vSphere Big Da

Windows 7和Windows Vista处理器、内存性能对比

Windows 7和Windows Vista的性能对比评测很多,但大多都是关于3D游戏的,不过玩游戏毕竟不是长久之计,所以今天我们再看看另外两个更基本的方面:处理器和内存性能. 测试平台配置: 处理器:Core i7-920 OC 4GHz (200MHz×20) 散热器:Noctua NH-U12P 主板:技嘉GA-EX58-UD5 显卡:技嘉GeForce GTX 285 内存:OCZ Blade PC-16000 DDR3 2GB×3 (7-8-7-20) 硬盘:西部数据VelicoRa

oracle 10g数据泵和导入导出性能对比(五)影响数据泵导入性能的最大因素

前一段时间在一次迁移中同时用到了数据泵和EXP,发现二者效率的差别还是相当大的.这里通过一个例子简单比较一下. 这篇文章讨论影响数据泵导入性能的最大因素. 前面写了几篇文章,分别介绍EXP/IMP与EXPDP/IMPDP的性能对比,根据前面几篇文章的描述,如果不使用并行,似乎IMPDP的效率要比IMP没有一个数量级的提示.对于当前的环境而言,事实确实如此.不过前面一直没有描述一个重要的因素,当然的数据库环境由于配置了STANDBY数据库,因此不但处于归档模式,还设置了FORCE LOGGING:

手机/笔记本/台式机CPU性能对比评测

  近日国外著名的PRIMATE LABS发布了全新的Geekbench 4测试工具,除了一如既往的支持跨平台对比,加入了更多的量纲指标来评估CPU和GPU的效能,比如调整了整数.浮点数.内存的各自所占比例,同时加入了GPU测试(Compute),多平台对比更加平衡. Geekbench 4是以Intel Core i7-6600U性能作为基准分数--4000分,自然高于4000分有更好的性能,而低于4000分则体验就逐渐降低.而上一代Geekbench 3则是基于Intel Core i5-2

最新显卡性能对比图

  电脑的性能主要由CPU.内存.硬盘和显卡来决定,内存和硬盘选择余地不宽,而独立显卡的型号太多了,怎么才能选择一款高性价比显卡呢?我们先一起看看下面这幅图,从图中可以轻松看出当前主流N卡和A卡的性能对比.(此文更新时间:2016年6月21日) 建议:显卡选择分为四个档次 入门首选: GT730K 1GD5(注:2GD5版本性价比不高,这个级别建议1GD5版本) 中级首选: GTX750Ti 中高首选: GTX950. GTX960 高端首选: GTX970.GTX1070.GTX1080 喜欢

远程桌面连接的多媒体重定向功能介绍及性能对比

  故障现象: 远程桌面连接的多媒体重定向功能介绍及性能对比. 解决方案: 远程桌面连接的多媒体重定向功能在客户端和主机端都支持时启用,其主要作用为在主机端播放的文件在客户端进行解码播放,而不是直接传送bitmap.其主要优势在于: 1. 节约带宽资源. 2. 节约主机的CPU资源. 具体效果对比,参照下图: