近段时间实在是比较忙。最开心的事莫过于期待以久的房子终于确定下来了，估计月底左右可以拿到钥匙，这阵子每逢俺那口子休息，总是要一起去看装潢材料什么的，用来构思论文和从事开发的时间明显地没有以前多了。
半年以前参与的那个CGI的项目这段时间客户反馈说有相当严重的性能问题，当用户的数据记录达到500条左右时，执行某些操作用时居然要达到惊人的65秒，恐怕没有几个客户愿意使用这样慢吞吞的系统。两周以来一直在从事系统的改进工作。分析了一下，这个系统的性能瓶颈主要集中在以下几个地方：
1、数据库的二次查询。这个系统原先在设计的时候支持Access和SQL Server数据库，使用ODBC来连接数据库。由于原先设计方式的限制，基本上系统只能使用单表查询的办法，在系统加入一些比较复杂的新功能之后，进行一些数据操作就需要多次地进行单表查询，甚至每两次单表查询中间还需要分配内存来转换数据。最恐怖的是二次查询，举个例子，第一次查询返回了500个结果，每个结果在进行数据转换的时候又要进行3次数据查询，一下子就是1500次，于是乎时间就达到了恐怖的数量级。最终修改的办法是使用多表连接查询，付出的代价是，系统不再支持Access数据库，因为发现Access数据库做多表查询总是有一些莫名其妙的问题，反正客户不用Access，也懒得去研究了。
2、海量数据的POST。这里说海量可能有些不合适，因为其实在数据只有500条的情况下，做POST的时候，初始化页面数据需要约9秒，解析数据需要27秒，加起来还是半分多钟，仍然是个令人无法忍受的结果。经分析代码发现，在页面上列出500条记录时，每条记录有两个checkbox用于设定状态，当点击页面最下方的按钮时，一共1000个checkbox的状态全部向服务端提交，总大小约为47K，十分惊人，而实际上服务端真正需要的数据一般只有极少的几条。由于页面的生成机制不值得进行大的修改，也无法改为使用多form单独提交的方式，我能想到的惟一的好办法就是舍弃POST机制，转而采用GET的方法，当点击按钮时执行一段javascript代码，它负责检测这1000个checkbox的状态，取出需要提交到服务端的数据，再直接进行页面重定向。这样一来，系统无需再进行页面数据的初始化和解析的工作，所需的时间也转移到javascript代码的执行时间上。最后改好的效果是：1000条记录下，页面javascript执行需要2~3秒，服务端执行时间1秒以内。这个速度，客户已经没什么可挑剔的了。
完成工作的感觉一直都是比较美好的哈。
PS：最近我的本本出现一个奇怪的现象，那就是在explorer中文件的右键菜单中最顶上一块菜单项似乎全部消失了，其它程序比如winrar在这一块区域注册的菜单项虽然还在但点击之后毫无反应，但是在最近使用文档或是桌面工具栏中从菜单项显示的文件的右键菜单却是正常的，Total Commander中的文件右键菜单也是正常的，奇怪之至，尚未发现原因，有高人知晓的，还望告诉一下，先谢谢了。
