Weird delay when writing a file
-
Flush is called by Close which is called by Dispose, which, of course, is called when leaving the using scope. So no, calling Flush before the won't actually do anything different.
I know the language. I've read a book. - _Madmatt
It would solve the mystery by exposing exactly what's causing the slowdown.
-
It would solve the mystery by exposing exactly what's causing the slowdown.
-
I am getting a weird delay when writing a file. I am not able to figure out where the delay is coming from. The facts: I map a drive to a NT server (W:\) I copy a file at W:\largefile.dat to W:\Archive\largefile.dat My copy loop:
try
{
using (FileStream sourceStream = new FileStream(nd_CopyDrive.LocalDrive + "\\" + fi.Name, FileMode.Open))
{
byte[] buffer = new byte[64 * 1024];
using (FileStream destStream = new FileStream(nd_CopyDrive.LocalDrive + "\\Archive\\" + fi.Name, FileMode.Create))
{
int q;
while ((q = sourceStream.Read(buffer, 0, buffer.Length)) > 0)
{
destStream.Write(buffer, 0, q);
}
}
}
}When the file is completely written my program hangs at the closing bracket for the second using statement. Nothing is shown in the Output window that gives me some clues. This block of code IS running in a background worker as added information. Could my problem be related to how the CLR "releases the memory used to store objects that are no longer required". If I place a debug marker at that ending bracket and perform a step into, the Output window shows:
Step into: Stepping over method without symbols 'System.IO.Stream.Dispose' (which takes forever to complete)
Any help would be greatly appreciated!
Have you trying just using File.Copy to see if there is any difference? It does basically the same thing but it may be something to test. Otherwise I'd say it's just the process of finalizing the writing of a large file, nothing you're going to solve without stepping into the unmanaged realm.
I know the language. I've read a book. - _Madmatt
-
Will it give information about network latency, data packets, etc.? No, it won't expose anything more than an extra statement to set a break point on.
I know the language. I've read a book. - _Madmatt
When you step over it, it will take a long time to execute the Flush statement. It would solve the mystery for me, maybe someone else would be too dense.
-
When you step over it, it will take a long time to execute the Flush statement. It would solve the mystery for me, maybe someone else would be too dense.
Richard Andrew x64 wrote:
maybe someone else would be too dense.
An uncalled for statement. If you can't remain civil then please don't comment. There are other ways to debug a problem than just hitting F10. Knowing and understanding the processing that are occurring is also a big help.
I know the language. I've read a book. - _Madmatt
-
Richard Andrew x64 wrote:
maybe someone else would be too dense.
An uncalled for statement. If you can't remain civil then please don't comment. There are other ways to debug a problem than just hitting F10. Knowing and understanding the processing that are occurring is also a big help.
I know the language. I've read a book. - _Madmatt
Look who's talking about being civil! You're the guy who's always breaking Rule 3 in HOW TO ANSWER A QUESTION.
-
Have you trying just using File.Copy to see if there is any difference? It does basically the same thing but it may be something to test. Otherwise I'd say it's just the process of finalizing the writing of a large file, nothing you're going to solve without stepping into the unmanaged realm.
I know the language. I've read a book. - _Madmatt
-
Look who's talking about being civil! You're the guy who's always breaking Rule 3 in HOW TO ANSWER A QUESTION.
-
Then again, I'd say there is nothing you're going to be able to do about it. Aside from performing the copy operation on the system where the files reside rather than going through a mapped drive.
I know the language. I've read a book. - _Madmatt
-
-
No fighting. Some people just resort to insults and deflection when their arguments can't be defended professionally.
I know the language. I've read a book. - _Madmatt
-
Oh, and I did add all these statements after the while loop:
destStream.Flush();
destStream.Close();
destStream.Dispose();Close is where it is hanging at. More thoughts?
As I said it's the process of finalizing and closing a large file. The data must be validated and header information written to the file and entries made in the FAT. Of course, performance may also be affected by the performance of your network and any IO operations also being performed on the destination disk.
I know the language. I've read a book. - _Madmatt
-
Then again, I'd say there is nothing you're going to be able to do about it. Aside from performing the copy operation on the system where the files reside rather than going through a mapped drive.
I know the language. I've read a book. - _Madmatt
-
Taking what you said
Aside from performing the copy operation on the system where the files reside rather than going through a mapped drive.
How can I do that?
Create a service on the machine which you can call or somehow trigger. Perhaps a WCF service, remember WCF isn't just for web, it is also used for interprocess communication
I know the language. I've read a book. - _Madmatt
-
Create a service on the machine which you can call or somehow trigger. Perhaps a WCF service, remember WCF isn't just for web, it is also used for interprocess communication
I know the language. I've read a book. - _Madmatt
-
svanwass wrote:
devices
:confused: I thought you were mapping a drive to a server? Anyway, not much more to be said. Other than decreasing the size of the file, which I'm sure is not an option, there isn't anything more you can do that I'm aware of.
I know the language. I've read a book. - _Madmatt
-
svanwass wrote:
devices
:confused: I thought you were mapping a drive to a server? Anyway, not much more to be said. Other than decreasing the size of the file, which I'm sure is not an option, there isn't anything more you can do that I'm aware of.
I know the language. I've read a book. - _Madmatt
-
I am getting a weird delay when writing a file. I am not able to figure out where the delay is coming from. The facts: I map a drive to a NT server (W:\) I copy a file at W:\largefile.dat to W:\Archive\largefile.dat My copy loop:
try
{
using (FileStream sourceStream = new FileStream(nd_CopyDrive.LocalDrive + "\\" + fi.Name, FileMode.Open))
{
byte[] buffer = new byte[64 * 1024];
using (FileStream destStream = new FileStream(nd_CopyDrive.LocalDrive + "\\Archive\\" + fi.Name, FileMode.Create))
{
int q;
while ((q = sourceStream.Read(buffer, 0, buffer.Length)) > 0)
{
destStream.Write(buffer, 0, q);
}
}
}
}When the file is completely written my program hangs at the closing bracket for the second using statement. Nothing is shown in the Output window that gives me some clues. This block of code IS running in a background worker as added information. Could my problem be related to how the CLR "releases the memory used to store objects that are no longer required". If I place a debug marker at that ending bracket and perform a step into, the Output window shows:
Step into: Stepping over method without symbols 'System.IO.Stream.Dispose' (which takes forever to complete)
Any help would be greatly appreciated!
try setting buffer length to less as possible but moderate enough. I usually use 512KB or 1MB buffer length for large file handling. Hope this will help you :)
-
I am getting a weird delay when writing a file. I am not able to figure out where the delay is coming from. The facts: I map a drive to a NT server (W:\) I copy a file at W:\largefile.dat to W:\Archive\largefile.dat My copy loop:
try
{
using (FileStream sourceStream = new FileStream(nd_CopyDrive.LocalDrive + "\\" + fi.Name, FileMode.Open))
{
byte[] buffer = new byte[64 * 1024];
using (FileStream destStream = new FileStream(nd_CopyDrive.LocalDrive + "\\Archive\\" + fi.Name, FileMode.Create))
{
int q;
while ((q = sourceStream.Read(buffer, 0, buffer.Length)) > 0)
{
destStream.Write(buffer, 0, q);
}
}
}
}When the file is completely written my program hangs at the closing bracket for the second using statement. Nothing is shown in the Output window that gives me some clues. This block of code IS running in a background worker as added information. Could my problem be related to how the CLR "releases the memory used to store objects that are no longer required". If I place a debug marker at that ending bracket and perform a step into, the Output window shows:
Step into: Stepping over method without symbols 'System.IO.Stream.Dispose' (which takes forever to complete)
Any help would be greatly appreciated!
-
Because the size of your file there's not much that can be done, but have you tried BeginWrite and EndWrite??? prolly asynchronous write can help...
I want to die like my grandfather- asleep, not like the passengers in his car, screaming!
