第一件事情，在C++端实现RPC（Remote Process Call）远程过程调用，C++端的RPC是模仿Go语言 的RPC实现的，其基础是培升写的多线程模型（也是多进程框架的基础中的基础）。RPC机制是由服务端和客户端组成，在多进程框架中一个基础服务，如DBService、AEService、CadService可以看做是服务端，业务服务调用基础服务时作为客户端，界面服务调用业务服务时，业务服务又成了服务端。RPC数据传输格式有多种，可以为XML、Json、Gob等，其中Json的数据量比较小，编码性能比较高，目前使用比较广泛，我们也采用Json作为数据传输格式。
遇到的问题：Json解析的性能问题，函数调用是很频繁的，在常规情况下，2.3GHz的CPU，1s中能够执行1000 000次加法。经测试，Json解析的消耗是RPC远程调用消耗时间最多的。市场上有很多Json解析库，如JsonKit、JsonCPP、CJson、LibJson等等，采用的算法大部分为状态机，但是其性能都不是很高，不能满足C++端的RPC调用。因此决定重新实现Json字符串解析。
这里只从整体上给出解决方案，如有朋友想有更深入的了解的话，可以与我联系，一起探讨学习。
解析优化方案：Json字符串可以与C++中的结构体一一映射，因为结构体可以套结构体，因此解析的时候每一次取值，只取第一层的，并对其位置建立索引。Json解析过程中，实现0拷贝，大大简化了解析性能。
编码优化方案：在Json对象内部采用多级缓冲的机制，去存放Json字符串。插入一条键值对时，计算键值对长度，如果第一级可以存放，则在第一级字符串的末尾追加键值对，键与键之间、键与值之间、值与值之间采用0字符分给，同时把键与值位置记录在索引中。删除一个键值对，只要从索引中删除就可以了。修改的话，就先删除索引，再执行插入。从而是解码过程中，实现0次拷贝，优化性能。
第二件事情，实现转换测试多进程框架，这个是业务的东西，就不多说了。
第三件事情，测试AE性能（这个叫坑啊，坑死我了），实现动态调图。
测试AE性能，真是坑人啊，整个公司CAD组也存在将近十几年了，组里面的人大家竟然一口同声的说AE提供的C++ COM接口性能低，让我这个新人深信不疑。让我从其他方向提供SDE接口性能，项目经理明确指出研究SDE Oracle表结构，直接从Oracle表中，获取图层信息，实体信息。大概研究了1个月时间，了解了SDE在Oracle中存储，以及实体的几何信息存储位置。但是，问题来了，几何的实体字段存储格式是ESRI加密的，非要调用SDE提供的Oracle包才能解析出来。这下麻烦来了，Oracle包是在服务器上执行的，也就是说是由Oracle执行包代码，我们管不了了，想利用多线程，多进程去解析没门，也就是说性能没法提高了。进入了一个死胡同了...
回过头来重新思考，ESRI的人应该不是吃干饭的，估计是他们使用的问题（因为AE接口是一个资深的元老级人物写的，大家都不愿看他的实现，即使看了，看出问题也没人愿意提出来，这些是中国国情导致的，没办法）。经追溯确实是这样，大不敬了。但是没办法有问题就是有问题，经再三思考下，还是提出来了，重新实现了一套接口，问题解决。
下面就是动态调图了，在CAD上动态调图其实就是模仿着百度地图、谷歌地图这些Web地图查看器做的。功能上也就是在CAD上拖拽、放大视图时，动态加载地图。
动态调图的核心思想是按照缩放级别， 对图层建立金字塔。其实说白了就是个四叉树，根据当前的缩放级别，以及位置，确定树的深度和节点索引，从而确定节点。而根据图层建立的四叉树，每个节点上是和若干个图层，以及一个范围绑定的，这样就可以根据范围从绑定的图层上取实体数据了。
在这就不详说了，大家有兴趣的话，给我留言。到时候我会根据情况，以及大家感兴趣点，写几篇文章出来，大家一起讨论。
扫一扫
89
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
