Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

multithreading is taking more time

Status
Not open for further replies.

ronaldo07

Programmer
May 19, 2006
5
0
0
US
Hi guys

Please dont make my fun,this is first time i am using threading in my code.

From following code I am expecting to write current time using
DateTime::Now (hh:mm::ss::ffffff)
But my problem is that I am seeing around 20 ms difference between two write. Why ??

Shouldn't it run continuesly with the speed of CPU (i.e. 2.6 Ghz in my PC)

I am posting part of the code ,I removed some useless text box codes.
and windows initialization is also removed .

Please have look and please reply



private: System::Void button1_Click(System::Object * sender, System::EventArgs * e)

{
ThreadStart *myThreadDelegate = new ThreadStart(this , dataReader);

trdTimer = new Thread (myThreadDelegate);

trdTimer->IsBackground = true;
trdTimer->Priority = ThreadPriority::Highest;
trdTimer->Start();
btn1->Enabled = false;
btn2->Enabled = true;

}



private: void dataReader()
{

while(true)

FileInfo *fleData = new FileInfo(S"Data.txt");
StreamWriter *swrSample;
if( fleData->Exists == true )
swrSample = fleData->AppendText();
else // Otherwise, create a new file
swrSample = fleData->CreateText();
swrSample->WriteLine( DateTime::Now.ToString("hh:mm:ss:ffffff"));
Thread::Sleep(0);
swrSample->Flush();
swrSample->Close();
}
}

private: System::Void btn2_Click(System::Object * sender, System::EventArgs * e)

{
trdTimer->Abort();
btn1->Enabled = true;
btn2->Enabled = false;


}

};
}
 
I'm guessing the 20ms is probably the time it takes Windows to task switch back to the thread.
 

I doubt it ,as I have read that people use mutithreading to read data from COM and process it with the speed of 1Mhz.

Which is 1000 time faster then my case.
 
Strange code: you are writing in a reader. Anyway, the problem looks like the file open/close. If you just open the file in the constructor and close it in the destructor, it will probably be a lot faster. You're also appending text, which means it is seeking to EOF. If the file isn't closed, then you only need to write without seeking to EOF, which takes a fair amount of time for a big file.
 
Actually Later I'm gonna use this to read data from I/O board thats why it has name Reader. :)

I did ,what u suggested nothing changed.
So its not File writting causing delay.

I even tried to write in listview ,but same delay there also.

There should be some another reason behind it.
I am surprised people are not able to find :(
 
Ronaldo (the one and only from Brazil ??? :) )

You moved the open to the constructor and the close to the destructor, but did you also move the flush to the destructor?
Flushing means all cache is written to disk, which will slow down file operation very much. Do not flush unless you really need to.
Also, flushing is useless before closing a file, because closing a file flushes it anyway.
A listview also is quite slow when adding huge amounts of lines.
What if you comment out the write operation completely?

Marcel
 
Yes I moved flush to the destructor.

If I remove write operation completely,How will I find if I am getting correct timing.
I need to varify ,somewhere I have to see times .
 
Sorry about gnomic short message before; I was in a hurry; 20ms just looked like a disk-access time to me at a glance, and I noticed you were saving the timings to disk rather than merely printing to screen, or putting them in memory somewhere and retrieving later, and wondered if you were actually timing your hard-disk rather than your ability to read the current time.
 
DateTime::Now approximate resolution is about 10 ms on modern Windows (and 55 ms on Windows 98!). So you can't detect 1 ms or less intervals at all with this timing interface.
Try to get time stamp in the thread before registration file opening. In any case you can't measure thread start/stop overheads with so roughly methods as low resolution time stamps and file open/close registration.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top