之前做了一个转Excel表到lua/二进制/json/xml的工具-xresloader。目的一方面是方便策划。另一方面是统一客户端和服务器的转表模式，并且要灵活适应环境变化。
最初做的时候考虑到既要方便Windows下策划和前端使用，又要方便后台部署在服务器上使用，甚至要集成在一些自动化的系统里。所以必须要跨平台。
并且需要对Excel操作比较好的Lib和对protobuf等各种协议操作比较方便的Lib。
所以综合考虑以后用了java来实现。
但是实际使用过程中，随着表格的数量越来越多，转换时间也越发地不可忍受。在做了简单地分析以后发现，在转换一个表格的时候，java载入jar包之后花了超过三分之二的CPU用于编译和编译优化java字节码。不到三分之一的CPU时间用于转表。而一次编译java字节码花费的时间要大约1秒钟左右。 这就意味着我们目前的70个表要花1分半中的时间编译java字节码，而实际转表只要不到半分钟。这果断是极大的CPU浪费并且等待时间太长了。
java的这个JIT功能对服务器程序是非常有用的，因为这样可以在编译期不需要像C 一样花费大量的时间，并且容易做跨平台的指令集抽象。实际开发中编译很频繁，java这个特性可以减少大量的开发中等待时间，而上线以后又能有比较好的运行效率。 但是这个特性放到命令行工具上就比较伤了，因为命令行工具一般都是执行次数频繁但是执行时间很短的，如果像这样每次运行去编译反而会浪费总体的资源和时间。最理想的情况是和_.Net Native_一样可以把它便以为本地应用。可惜java貌似还没这个功能。
而我尝试关掉java的JIT时，实际时间会更长，所以就有必要针对Java这个特性做一些特别的优化。 仍然是为了容易和其他工具集成，所以我这里设计成了可以通过stdin来获取多次转表的信息。还有一点就是要把单例的部分在下一次转换的时候清理掉。 然后批量转表工具xresconv-cli和xresconv-gui都接入新的转换方式。通过管道来控制子进程的标准输入，以此来控制转表内容。 实际优化后的效果相当明显。虽然我懒得把对比数据跑出来了，但是原先70个表每个需要超过1秒钟，4个并发任务总时间也会需要十几二十秒，而现在2个并发任务的情况下，总转换时间6秒左右。 现在的转换步骤里，转第一个表的时候大约需要1秒钟，然后剩下的前十个左右大约在0.2-0.4秒钟。再后面的速度就是”刷得一下“就结束了。 可以很明显地感受到java JIT的第一次编译优化，运行频繁以后的第二次更深度优化带来的性能提升。后面一批转表感觉上速度提升有_十倍_以上。
然后我测了一下2个并发任务和4个并发任务时的区别，2个并发任务的情况下更能发挥java的JIT优势，耗时6秒左右。而4个并发任务时虽然进程数更多，但是JIT优化的效果会降低很多，反而总时间在9秒左右。 而单线程时JIT效果最好，但是总时间感觉比2个并发任务略慢一点点。（我的机器是4核8线程的CPU，型号是至强 E3-1230 V2）
所以我把批量转表工具的默认最大并发度都限制到了2。 总的来说，这次的优化效果还是很明显的，虽然在批量转表的情况下还有一些优化空间（比如macro表几乎不变，可以缓存下来），下次有空再说吧。
