|
I supose it really only works for vector-fonts since a raster-font probably has nothing to put into a path...Anyways, isn't that solution a bit slow?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
I did a test in debug mode with breakpoints...(not the best way to check)
1000*1000=1,000,000 loop
It was only 5 sec.
a normal textout will not export so much as so.
Update...
CSize sizeText;dc.GetTextExtent(str,str.GetLength(),&sizeText);
for (int x=r.left;x<sizetext.cx;x++)>
{
for (int y=r.top;y<sizetext.cy;y++)>
....
modified on Monday, December 29, 2008 9:34 AM
|
|
|
|
|
On some files fclose is taking long time to close the file.Can someone please tell that in which condtion it can take time to close and how it is internaly implemented?
Thanks in advacnce.
Regards,
Vishal
|
|
|
|
|
Try calling flush() to flush all writes to the file before calling fclose().
This may reveal that the cause of the slowness is the buffered writes.
|
|
|
|
|
Thanks Richard.
I have tried fflush before fclose.fflush returns immidately but fclose is taking time.time for closing the files get increased with increase in file size. with 100MB it is 30 sec.With 200MB,it is 1 min and 300MB it is 2min and so on.It is happening with one type of files(.dat files) only.I tried by closing some other file at same path with same code and this file is closed immidately.I have tried everything but I am not able to find the reason.Please give some other sugestion,I can try.
Thanks
Vishal
modified on Sunday, December 28, 2008 4:18 AM
|
|
|
|
|
Hi,
is there anything special about your file? e.g. is it on another PC, in a special folder, ...?
does it need some post-processing, like compression, encryption, ...?
|
|
|
|
|
Thanks Luc.
There is nothing special about this file.It is just *.dat file in which logging message are written.It is not in another PC and it is not in special folder.
To confirm this,I have also tried by putting some other file with same size on this folder and rename in to culprit file name but this file get closed immidately.
After completion of this file(on day change new file is created), it is processed by some other modules to create the reports.
Thanks,
vish
|
|
|
|
|
The source code comes with Visual Studio.
Why not step into the fclose() code with the debugger and see what's
happening?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Thanks Mark.
I tried to debug "fclose" on my m/c.It is not going inside of fclose.
I am not able to see its code also.I was assuming that only header files comes with visual studio.
If I can see its code then it would be great help.Could you please tell that at which location these
source files are?
Althogh this problem is not reproducible on my local m/c.It is happening on live system only.
Even then,I can see code and put some OutputDebug strings to see where it is taking time.
Please tell that how can I step in to fclose?
Thanks,
Vishal
|
|
|
|
|
What version of Visual Studio are you using?
I see fclose() implemented in the file C:\Program Files\Microsoft Visual Studio 9.0\VC\crt\src\fclose.c
on Visual Studio 2008.
I would guess the delay is happening when the buffered contents are flushed (i.e. actually written)
to disk. You can check by opening the file with the commit flag (c) and calling fflush()
(without that flag, fflush() returns immediately).
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Earlier I had doubt related to fflush or some other factor.To know this first I tried by calling fflush just before fclose.It does not make any difference.
Then in second test ,I tried by just open and close the file.Nothing in between these two.
even in this case it was taking time.
I wil try by giving "c" in file open mode.Now I opening the file by "a+",I will change it by "ca+".
Can I also put some logging message in fclose it and recompileit lirary?
Thanks,
Vishal
|
|
|
|
|
Vishal Kumar Soni wrote: first I tried by calling fflush just before fclose.It does not make any difference.
Correct. fflush() doesn't flush without the commit flag.
Vishal Kumar Soni wrote: Can I also put some logging message in fclose it and recompileit lirary?
Much easier to use the debug CRT library and step into it with the debugger.
Surely if you have the CRT source code to do a rebuild, you should be able to
step into the debug build of the library 
Also, if you don't like the performance of fopen/fclose file I/O, there are other options...
like direct Win32 calls.
If you don't want data to be buffered, you'll need to use unbuffered I/O
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanks Mark.
Each of your message helping me to get close of the problem.
I tried to put some OutputDebugString message in fclose.c . Now I am not able to find the way by which I can compile this file.Could you please tell that how can I do this?
other thing. Is there difference ,If I create the file by giving name either "a.dat" or "a.log" . creating log file by name *.dat makes any differnece in internal handling of file.
I have also observed that this problem is not happening on my local m/c.It is happening only on live system and that m/c is on windows server 2003.So fclose is related to OS?
Thanks,
Vishal
|
|
|
|
|
I have tried by giving "c"in mode while opening the file.I fflush before closing the file.It returned immidately.
So I think fflush is not culprit here.
As per fclose code.It does following four steps
1 flush
2 free buffer
3 close file
4 delete temp file.
I think it might be something related to free buffer.
Thanks
Vishal
|
|
|
|
|
Vishal Kumar Soni wrote: I think it might be something related to free buffer.
Were you able to step into the code or are you guessing?
Like I said, if the buffering implementation doesn't perform
the way you need it to, then you need to use a different I/O method.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
It was guess.
I have also tried by setvbuf to set the buffer to zero.It is also not helping.
Other strange thing I found that,if I right click on that file to see properties even then it is taking long time rahter then othe files with same size on same location.
Could you please tell the way by which I can step in to fopen code to put some debug message?
Thanks,
Vishal
|
|
|
|
|
You can also try using setvbuf()[^] to use a smaller buffer size (or no buffering).
I don't recall what the default buffer size is.
Something's really wrong somewhere if it's taking minutes to close a file of a
couple hundred MBs.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I have found something related to this problem.I talk with neotwork and admin guys and requested them to turn off the antivirus on that m/c.After that it worked fine.So it might be due antivirus we were not able to close this file.I will test this 1 day then I will confirm.
Thanks lot!
Regards,
Vishal
|
|
|
|
|
Oh yeah - antivirus software will slow it way down
As far as stepping into CRT/MFC code....
Make sure you are linking to the debug version of the library(s).
Put a breakpoint on the fclose() call.
Run in debugger.
When the breakpoint is hit, use F11 to step into the library code.
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi,
you did not mention a temp file before. What is it for?
deleting a file may take several seconds, i.e. Windows may try and try again, when the file happens
to be busy, such as being read by some great utilities (Antivirus and indexing software are very
interested in newly created files).
Without a temp file, there would be no delete involved, hence this possible delay does not occur.
|
|
|
|
|
Thanks Luc.
I checkeked the internal implemation of flcose then I found following comment in fclsoe function:
/* Stream is in use:
(1) flush stream
(2) free the buffer
(3) close the file
(4) delete the file if temporary
*/
from here I got that it deletes temp file in some cases.I cheked on my that it is not creating any temp file.
Another strange thing I found that if I right click on that file to check its properties then it also takes very much time to show properties as compare to other files with same size and at same location.
|
|
|
|
|
OK, Windows Explorer being slow in accessing the file tells us two things:
1. the problem probably is not in your app
2. something is wrong, or you forgot to give some relevant information.
Time to become very specific:
1. what is your OS?
2. what is the full path of your slow file(s)?
3. is it consistent, i.e. is it always slow for a specific file?
4. what is the size of the file?
5. is anything special about its folder? is it shared? is it being virtualized?
etc.etc.
|
|
|
|
|
I wanted to share this great resource with all of you guys.
C++ FAQ Lite is a free C++ online tutorial, for more info, visit the
home page:
http://www.parashift.com/c++-faq-lite/index.html
To download a CHM (legal+free) version of the tutorial, please visit
this page:
http://lawand.wordpress.com/site-map/computer-science/e-books/cpp-faq-lite/
Best Regards.
|
|
|
|
|
Please no advertising on this forum.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
What made you consider this an advertisement ?
This is a free tutorial which content is relevant to this forum right?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
