Logging to files
Author
What is the best way for a game to to log data to files? Do you open the file at initialization and keep it open the entire time your program runs, or do you open, write, and close the file everytime you log something?
I think that opening it once and keeping it open for the duration of the game is best, because if you tried to run two instances of the app, you wouldn''t have both programs writing to the same file, which would make the data confusing.
On the other hand, if your program crashes, what happens to the open file? Does the data become lost? If so maybe open, write, and close is the best choice.
Another idea might be to start each line with the process ID, and then you can have everything go to the same file, and filter out what you want (using grep). Or you could write to different files, using the process id as part of the name.
So what do you think?
Open at the beginning, and close on program termination.
If you need to log right up to a crash, you can just flush the file buffer after logging a message. This is much faster than opening and closing everytime you log, and ensures good logs after a crash.
If you need to log right up to a crash, you can just flush the file buffer after logging a message. This is much faster than opening and closing everytime you log, and ensures good logs after a crash.
freopen(stdout, "MyLogFile.txt");float Bar = 4.5;printf("Init started");printf("Value: %f", Bar);printf("Ending app...");That, my friend, is what you do. freopen with stdout redirects the standard output stream (used in printf commands and the like) to the file specified. What this will do is automatically save what you write to the file as you do it, when your app crashes the file won''t be erased, and you don''t have to open and close a file constantly. YOu don''t even need to close it at all; since it''s stdout it automatically closes with your app. Same goes for stderr.
Walt
printf is buffered, no? If the program crashes before the stream is flushed you''ll lose everything in the buffer. But you don''t want to flush all the time, because those disk operations could kill you.
Author
With what frequency is it ok to flush? Will once or twice a second slow things down significantly?
Slow it down significantly?
File Access is about 110% slower than memory access. We actually had a real-time scanning program slow down very noticeably because of logging to file caused lots of writes. The best logging system should minimize the time needed to write, perhaps with memory mapping files (MapViewOfFile). Or designing a buffered logging system(Storing logs in memory of another program) to prevent it from loosing data upon a crash.
What I would do:
But consider this, in release mode you can probably turn logging off; so for now I would be concerned with implementing a simple logging function to a file and not worry about performance.
"Optimization is the root of all evil."
You can make an elaborate logging function, but you ask yourself is that what you really want to do?
-------
Homepage: http://students.washington.edu/andrey
File Access is about 110% slower than memory access. We actually had a real-time scanning program slow down very noticeably because of logging to file caused lots of writes. The best logging system should minimize the time needed to write, perhaps with memory mapping files (MapViewOfFile). Or designing a buffered logging system(Storing logs in memory of another program) to prevent it from loosing data upon a crash.
What I would do:
But consider this, in release mode you can probably turn logging off; so for now I would be concerned with implementing a simple logging function to a file and not worry about performance.
"Optimization is the root of all evil."
You can make an elaborate logging function, but you ask yourself is that what you really want to do?
-------
Homepage: http://students.washington.edu/andrey
quote:
Original post by Russel
I think that opening it once and keeping it open for the duration of the game is best, because if you tried to run two instances of the app, you wouldn''t have both programs writing to the same file, which would make the data confusing.
I was going to give that as a strong point of opening the file at each write point. To test the network mode of my game I simply ran two version of the program from the same directory. All the messages exchanged by the two instances appeared in the same report file in the exact order in which they were issued.
1) Your app probably won''t have 2 instances running in debug mode.
2) You will have to write out to disk every time, unless you are willing to lose data.
3) Opening files is really slow, because of all the permission checks.
4) with stdio, you can fflush expliticly or disable buffering with setvbuf (better).
2) You will have to write out to disk every time, unless you are willing to lose data.
3) Opening files is really slow, because of all the permission checks.
4) with stdio, you can fflush expliticly or disable buffering with setvbuf (better).
Make a simple debugger program that just has a console-like text box and make it accept a certain user message that means "Log this text". Then all you need to do from your game is find the window by title and send that message whenever you want to log. Don''t need to write to disk, and you don''t lose the log if just the game crashes.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
