与线程和事件的使用相关的性能问题??? [英] Performance issues related to the use of Threads and Events???

问题描述

在我的基于MFC对话框的应用程序中，有2个父线程，在父线程中有3个子线程，它们使用CEvent进行同步-SetEvent()和ResetEvent().
输入文件被读取为16个字符的块.共享缓冲区用于存储块.

子线程1-用于从文件1中读取一个块(16个字符)
子线程2-用于在线程1读取的块上执行某些任务
chikd thread3-用于将修改后的块写入file2

这三个子线程处于while循环中，直到块> 0.

子线程1为子线程2设置事件，子线程2为子线程3设置事件.

对于大文件，应用程序的运行时性能非常差.

In my MFC dialog based application there are 2 parent threads and inside the parent thread there are 3 child threads and these are synchronized using CEvent-- SetEvent() and ResetEvent().
The input file is readed as blocks of 16 char.Shared buffer is used for storing the blocks.

child thread1 -- used for read a block(16 char) from file1
child thread2 -- used to perform some task on block readed by thread1
chikd thread3 -- used to write the modified block to file2

These three child thread are in while loop until block > 0.

The child thread1 sets event for child thread2 and child thread2 sets event for child thread3.

The run time performance of the application is very poor for the large files. How can I increase the performance as the application runs very slow?

推荐答案

当然，纯:
您已经失去了通过这种技术进行的多线程处理，
由于您的线程运行不平行... :)

我会按照以下方式解决它:

0.通过关键部分(对于线程1和3)控制文件访问

1.在第二个关键部分分配一个保护的整个大小的缓冲区

2.控制由第三关键部分保护的群集列表中缓冲区的群集"

2a.第一个线程在其循环和
中逐个文件读取文件 2aa.用读取的簇填充缓冲区
2ab.在列表中添加标记为"ReadyToModify = true，BlockOffsetInBuffer = x，BlockLengthInBuffer = y"的条目

2b.第二个线程遍历列表，以查找标记为"ReadyToModify = 1"的下一个条目.
2ba.将群集从缓冲区读取到本地缓冲区
2bb.修改本地缓冲区
2bc.通过本地修改的集群填充缓冲区
2天将列表条目标志设置为"ReadyToSave = 1"

2c.第三个线程遍历列表，以查找标记为"ReadyToSave = 1"的下一个条目.
2ca.将群集从缓冲区读取到本地缓冲区
2立方英尺将本地缓冲区保存到文件中

Pure, of course:
you have lost the multithreading processing by this technique,
since your threads are working nonparallel... :)

I would solve it like following:

0. Control the file access by a critical section (for thread 1 und 3)

1. Allocate a protected by a second critical section the whole-sized buffer

2. Control the "clusters" of the buffer in a cluster list protected by a third critical section

2a. The first thread read a block by block from the file in its loop and
2aa. fill the buffer by the read cluster
2ab. make an entry in the list with the flag "ReadyToModify = true, BlockOffsetInBuffer = x, BlockLengthInBuffer = y"

2b. The second thread iterate the list to find the next entry marked by "ReadyToModify = 1"
2ba. read the cluster from the buffer to a local buffer
2bb. modify the local buffer
2bc. fill the buffer by local modified cluster
2bd. set the list entry flag "ReadyToSave = 1"

2c. The third thread iterate the list to find the next entry marked by "ReadyToSave = 1"
2ca. read the cluster from the buffer to a local buffer
2cb. save the local buffer in to the file

首先:在通话时，您需要显示数字.只能猜出_why_应用程序运行缓慢.

但是，跳出您的问题的一个数字是数字16:从file1读取16个字符" ...

文件访问是程序中最昂贵的程序之一:磁盘等待时间等...您的程序似乎受IO限制.您可以尝试确定瓶颈是否是文件IO.我认为答案是是".

假设文件IO是瓶颈，请尝试限制它:一次读取较大的块，从而排除磁盘读取的开销.

并且:不要指望魔术:更大"的文件将花费更大"的时间.问题是它是否在合理范围内.

First: when talking performance, you need to show numbers. One can only guess _why_ the app is slow.

However, one figure that jumps out of your question is the number 16: "read 16 characters from file1"...

File access is amongst the most expensive in a program: disk latency etc... Your program seems to be IO-bound. You could try to figure out whether the bottleneck is the file-IO; I assume the answer will be "yes".

Assuming file-IO is the bottleneck, try to limit it: read bigger chunks at a time, thus ruling out the disk-read overhead.

And: don''t expect magic: ''larger'' files will take ''larger'' amounts of time. The question is if it''s within reason.

这篇关于与线程和事件的使用相关的性能问题???的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！