在解析数据时采用线程池与并行库效率的比对

Coordinator
Mar 27, 2012 at 4:14 PM

当设置CPUConut = 2时

Time of reading data:4328.125

Time of parsing data by threadpool:21312.5

Time of parsing data by TPL:20781.25

 

当设置CPUCount = 4时

Time of reading data:3812.5

Time of parsing data by threadpool:21390.625

Time of parsing data by TPL:20921.875

我自己的笔记本电脑的配置是双核 Windows XP SP3

 

总之,并行库是要比线程池快一点儿,但是相差也不大,不知道在四核 Windows 7上跑跑是什么结果。

Coordinator
Mar 27, 2012 at 4:35 PM

并行库比较好的是写起来代码易读性好,而且自动根据当前系统硬件进行线程分配。

理论上线程池和并行库的效率不会相差什么,只是编程的方便性增加了。

不像我们还得检测cpucount,分配每个线程应该做的工作量之类的事情。

 

另外,用并行库的时候,你怎么解决的正则表达式共享问题?还是每次都new一个,那样会浪费资源的,因为compiled选项是要求编译的。

 

编译正则表达式我想也耗费时间。

 

 

 

 

Coordinator
Mar 29, 2012 at 8:24 AM

并行库这块儿的东西我又做了一点儿小的修改,速度能快1S多一点了,能快点儿是点儿吧。

CPUCount:2

Time of reading data:4531.25

Time of parsing data by threadpool:22234.375

Time of parsing data by TPL:21015.625


这个是TPL共享一个regex的结果,互斥的开销还是比较大的,比为每个线程都new一个regex时要多花费近11s的时间。

CPUCount:2

Time of reading data:4546.875

Time of parsing data by threadpool:21671.875

Time of parsing data by TPL:32359.375

 

PS:正则表达式确实是较耗费时间的,但用起来也确实很方便,然后说到正则表达式的共享问题,我还没想到什么好的优化方法,不知道大家韩老师和虎哥有没有什么好的建议和想法。

Coordinator
Mar 29, 2012 at 9:58 AM
Edited Mar 29, 2012 at 12:32 PM

我觉得这段的优化潜力不大。所以只要做成cpucount是自动检测出来的也就差不多了。

 

至于正则表达式的共享问题,不知道你问的是否是指多线程共享一个?

我目前的实现方案是没有这个问题的,因为每个线程都new了一个实例,故此不存在并发访问冲突。原来只有4个线程,每个线程new一个regex也就是4次new.

我指出的每次都new一个是指使用并行库的情况。

并行库由于没法明确指定在哪个线程里面创建regex,所以才有可能控制不住创建多少个regex的问题。

我不清楚你怎么解决的。我想也许并行库有更具体的用法我没仔细看。

建议继续其他部分吧。我列出来的待做事项还有很多。按理说优化代码的第一个前提就是不优化没有太大潜力的部分。从理论上分析就没有他太大潜力的事情暂时可以不做。因为如果每处都要优化的话,几乎就不可能有精力完成一个有点价值的系统。所以说优化的第一步通常是评估什么东西应该并且能优化什么东西不优化。


Coordinator
Mar 29, 2012 at 1:33 PM

我上面的数据已经说了,如果并行库共享一个regex的话,比每个线程都new一个要费时的多。