1.圈选删除节点慢的问题已经解决；2.后处理中，统计量比较多时，计算慢，进一步确定了问题的原因

今天把圈选大量节点然后删除，删除效率低这个问题单解决了，在此做个简单的总结。

这个问题单此前修改过一次，但是提交后测试没通过，原因是只减少了Ctrl+A全选后的删除效率，圈选大量节点后删除的效率仍然很低。（当时只修改了和刷新相关的地方，减少了界面刷新次数，这样删除时也会较快，但是）

原因分析：Ctrl+A选中节点之后，节点被有序(nodeID由小到大)的添加到选中节点列表中，而圈选的节点在选中节点列表中是无序的。删除一个节点时，会从界面上按照nodeID由小到大的顺序取一个节点，并判断该节点是否是选中节点列表中的元素，如果是，则删除，如果不是，则取下一个节点进行判断。当选中节点列表中的元素是无序时，要确定一个节点是否是选中节点列表中的元素需要进行多次比较，而如果选中节点列表中的元素也按照由小到大的顺序排序，比较次数就会少很多。

解决方法：1.在执行删除命令之前，对选中节点列表中的元素进行排序，使得选中节点列表中的元素按照由小到大的顺序排列，这样在确定一个节点是否是选中节点列表中的元素时就只需要少量的比较。这种解决方法大大提高了删除效率，改进前删除1万个节点需要近20秒，改进后只需要不到300毫秒。但是，仍然有一个问题：删除后，按Ctrl+Z进行恢复，然后a.再次圈选并删除，会很慢;b.Ctrl+A圈选再删除，也是很慢。也就是说，这个问题没有完全解决，甚至引发了新问题（Ctrl+A圈选再删除，也是很慢），原因在在哪里？

2.原因是：Ctrl+Z恢复的顺序是，最后删除的最先恢复，这就使得恢复后节点的顺序变成了由大到小的顺序，这样每删除一个节点都需要进行多次比较。当然，解决的方法也是比较直接的，就是Ctrl+Z恢复时，让最先删除的最先恢复，这样恢复出来的节点仍然是按照由小到大的顺序排列的。

后处理部分的效率问题，是由于多次访问ov文件导致的。当前的现状是：当统计量很多时，计算很慢;原因是，每个统计量都会执行如下步：打开文件，访问数据，关闭文件。访问文件的效率是比较低的，这样统计量越多，计算就会越慢。

解决的方法为：减少IO的次数。但是，如果一个统计量很大的话，这样做就会遇到内存装不下数据的问题。