Deer计划（1）点云数据解析成图

Deer计划（1）点云数据解析成图 第一part 点云数据的解析成图

需要自行配置jsoncpp、OpenCV运行环境

1. 点云数据的解析成图模块设计

测试环境

i5-9400f 16g (测试情况和实机性能有关)

线程解析（以法如的三维扫描仪生成的fls文件为基础）

1.多线程解析数据效率

项目c++耗时解析一个fls20秒解析3个fls25秒解析6个fls37秒解析7个fls46秒解析9个fls57秒解析15个fls96秒解析20个fls134秒解析40个fls266秒解析-加载里程-解析空间(单文件)240秒解析-加载里程-解析空间-成图(单文件)291秒解析-加载里程-解析空间-成图(两个文件)291秒解析-加载里程-解析空间-成图(5个文件)667秒解析-加载里程-解析空间-成图(6个文件)727秒

2.单线程和解析

项目c++耗时解析一个fls20秒解析6个fls104秒解析7个fls127秒解析15个fls260秒解析20个fls376秒解析40个fls729秒

3.新环境重测 （i7-9700+16g+GTX1660Ti ）

单线程解析 此过程只是解析fls，并不包含成图 项目c++耗时2021年11月23日下午3点重测（占用内存）解析一个fls10秒c++：16秒(243MB)解析两个fls31秒c++：33秒(310MB)解析三个fls47秒c++：49秒(288,6MB)解析四个fls64秒c++：65秒(278MB)解析五个fls80秒c++：84秒(311.4MB)解析六个fls95秒–

2021年11月23日下午3点结果：
每个fls解析的平均时间：c++===》16.42秒

单线程成图

扫描仪生成一个FLS文件的时间是约30S
此测试过程包括解析fls—里程解析----空间解析处理----成图

项目c++第一版耗时（精度、占用内存）c++第二版优化耗时（精度、占用内存）一个fls成图150秒（2mm、4G）26秒（2mm、3.9G） 26秒（5mm、3.8G）两个fls成图303秒（2mm、4G）53（2mm、4.4G） 53秒（5mm、4.4G）三个fls成图453秒（2mm、5G）79秒（2mm、5.0G） 78秒（5mm、4.9G）四个fls成图602秒（2mm、6G）105秒（2mm、5.1G） 103秒（5mm、5.4G）五个fls成图757秒（2mm、6G）131秒（2mm、6.1G） 128秒（5mm、6G）六个fls成图911秒（2mm、7G）157秒（2mm、6.6G） 154秒（5mm、6.6G）

第一版是在i5处理器上进行的，之后我做了调整，就在i7处理器上运行了

第二版的测试情况

• 2mm（成图的精度，不懂的自行查阅OpenCV）成图内存占用情况
  
• 2mm成图cpu占用情况
  
• 5mm成图内存占用情况
  
• 5mm成图cpu占用情况
  

1. c++第一版的运行过程中出现132秒长时间的占用4G内存的情况
2. c++第二版的运行过程以梯度的形式占用内存，也就是上表中占用内存的记录只用1秒，之后又会逐渐减低。减少在磁盘的读写频率

多线程解析

多线程解析fls(当前环境同时开了10个线程解析fls效率出现严重低下，所以没有10个以上的多线程解析数据分析)

项目c++耗时（消耗内存）解析两个fls10秒（453M）解析三个fls22秒（743M）解析四个fls25秒（911M）解析五个fls29秒（1G）解析六个fls32秒（1G）解析七个fls37秒（2G）解析八个fls39秒（3G）解析九个fls43秒（3G） 多线程成图（成图过程和单线程一样） 项目c++耗时（消耗内存）c++第二版优化耗时（精度、占用内存）两个fls成图216秒（5G）37.4秒（2mm、7.7G） 35秒（5mm、7.8G）三个fls成图250秒（9G）45秒（2mm、11G） 46.1秒（5mm、11.6G）四个fls成图320秒（13G）65秒（2mm、15.2G） 61秒（5mm、15.3G）五个fls成图380秒（15G）–（2mm、19G）内存过载，本机暂时无法完成测试六个fls成图470秒（18G）– 测试情况

• 2mm成图多线程解析2个占用情况
  
• 2mm成图多线程解析3个占用情况
  
• 2mm成图多线程解析4个占用情况
  
• 2mm成图多线程解析5个占用情况
  
• 5mm成图多线程解析2个占用情况
  
• 5mm成图多线程解析3个占用情况
  

4.图片质量

5.设计思路

• 数据存储
  * 问题：数据的处理量达到了上千万级别，在程序运行一段时间之后，再次进行数据读入 *** 作，会出现内存溢出的异常。
  * 原因：对较大的数据量的数组进行较为频繁的读入 *** 作（数组大小为500M以上），在循环中创建了多个对象。
  * 解决：c++版本采用容器代替数组来承载数据，安全、防止爆栈
  * 对比起数组，vector是安全的（假设一个arraylist里现在只有给产品可以消费，但是有两个消费者线程请求消费，数组就会出现：可能出现一个产品被同时消费的问题，这与实际不相符。至于vector容器不会出现数组的问题，因为内部机制是同一时刻只能有一个线程对这个变量 *** 作）
  * 防止爆栈，用于存储对象的数组存放在栈中，一般机器的栈大小是1~2M，vector存在堆中，对象是存在堆中，windows的堆空间，约2G。
  1. 指针大小：内存是由字节组成的，每个字节都有一个编号。指针变量主要是存放相同数据类型的变量的首地址。这里的这个地址其实就是内存的某个字节的编号。而这个编号的确定是与地址总线有关。如果地址总线是32位，则它的寻址范围是02^32（04G）。那么为一个字节的编址就会由32个0或者1组成。例如第一个字节的编址是32个0，最后一个的编址是32个1。一个字节有8位，32位则需要4个字节。
  2. 对象大小：组成（对象头8字节，指针4字节，数据存储区域（不定，int是4字节，char是2字节），对其补充（补充到整个大小为8字节的倍数）），存储int类型对象是16+x，存储char对象是14+x
  以上储存int对象的大小是指针的4倍以上。
  使用openCV生成当通道图，8byte（成对象的图像数据需要byte类型），byte对应的c++版本是unsinged int
  1MB = 1048576字节 = 32768个int对象（c++）
  2MB = 2097152字节 = 65536个int对象（c++）
  2G = 2048MB = 2147483648个字节 = 67108864个int对象
  单个fls解析出来的数据量是19492421个对象，无论是1M还是2M的栈空间都不够存放
  存放在堆空间的情况下，可解析的fls内容量可以是现在fls数据量的3倍
  3. 实际上c#版本，正常来说，已经出现爆栈的情况 得益于c#对内部分段计算优化，在C#中使用数组，可以获取在内存上连续的相同类型的一组变量，在连续访问时可以满足CPU访问寄存器的时间局部性和空间局部性，大大提高了对大量数据的访问效率
  当然你可以手动的去给栈分配更大的空间来防止这样的情况。

6.运行过程

7.源码地址 大家参考和共同学习 谢谢
https://gitee.com/lihenggeek/deer-project.git