krproject开发进展(十二)

这篇应该不属于krproject的开发进展内容,但绝对是属于krproject的文章,暂没想好区分,索性放在一起了。

过去的这两个礼拜,对krproject来说,也应该算是个值得纪念的日子吧,准确的说是krproject的首秀!虽说之前krproject的前身已经在某国有大行成功实施,但彼时的系统受环境、政策等因素限制,相对于后来改版后的krproject,性能和易用性都有较大的差距。但是新版的系统,毕竟一直都是在我的虚拟机里或者公司的测试机上默默运行,一直没有机会拉出去晒晒太阳~

上两个礼拜,偶然的机会,krproject得以小试拳脚,结果还是很令人满意的,虽然在实战时还是暴露了自身的很多问题和不足,但是初出茅庐的它竟然在性能上有比其他同学高出近百倍来……,它的小巧、简洁、语义清晰等特性也是让人眼前一亮。

看到它有一天终于开始要发光发热,想起一路磕磕盼盼的走过,也曾受过质疑与挑战,却依然固执与坚持。这一刻,会觉得它是个争气的小孩!嗯!

好了,牛就吹到了这儿了。老实记录下krproject首秀过程中暴露出的不足吧:

最大的问题俨然是出在rapodbc身上,当时作为取代embedded sql的小工具,花了几天时间,但并没有详细测试过,尤其是插入和更新是有问题的……,修改完善后,发现又没有实现错误信息的获取,也是让我吃尽了苦头。代价就是最后性能测试没有得到完美表现,真是遗憾……!所以基础小工具的完善绝对是搭建大工程的最重要基础,一点不可马虎。

其次就是上次重构后的遗留,上篇日志提到了重构,其实每次代码重构都藏了一些坑,里面有诸如:增加KR_TYPE_LONG类型后,运算器模块没有包含及时更新; 集合改为动态加载后,运算器模块相关type/value的获取方式调整; 统计量整合后,线程上下文的清理机制等等。

再有就是线程池的broadcast机制了,这倒不难,我也是在那几天时间里,将他实现了,但其实我很早就想将我的线程池再完善一下了(在读nanomsg源码的时候),结果一直拖到节骨眼上,才临时上了个人认为实现的不够完美的版本。

最后还是日志信息,我对现在的日志打印还是不满意,不能简洁直观的反应问题所在,这显然不利于寻找和解决问题。

以上的这些都会是下阶段krproject的完善工作。

PS:因为一些原因,我将github上的krproject撤了下来,各位如果有对源码感兴趣的同学可以写邮件说明情况向我获取。由此带来的不便,还请见谅。我会在合适的时机,重新开源的!