Archived

This topic is now archived and is closed to further replies.

Dwarf with Axe

safe to open a file everyframe?

Recommended Posts

Hi, I was just wondering if it was safe (on performance & the processor) if I were to, every frame: open a file, extract information, close file open the file, write some stuff, close it again The files would be small, less than 10kb text files... THe reason I''m asking is because I want to buffer the input of a chat box into a text file. ~Dwarf

Share this post


Link to post
Share on other sites
in short its not advicable, you can surely do this without a txt file, i was a little more awake i''d produce a sample. Perhaps someone else will, otherwise i''ll be back later

Share this post


Link to post
Share on other sites
dwarf:if you do it everyframe it will be a performace killer. if you do it once a sec it might be acceptable, althrought you should avoid it like fire.

few tips:
1.leave file open if possible
2.read/write all data with one call, don''t perform many read/write operations as they are v.slow. It''s much faster to load everything into memory and work from there.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
If you *really need* to write to it every frame (more or less), why not keep it open all the time, and flush after every write (or after a few writes to increase performance). That way if your program crashes the file will still contain the data. Only unflushed data would be lost. There is certainly no reason to open it twice each frame (as your description suggests, once to read stuff and once to write. Just open it in modify mode allowing you to both read and write).

You will of course still lose a lot of performance if you write to a file every frame, but at least you won''t incur the overhead of opening and closing the file all the time.

The only valid reason I can think of to do anything like what you''re doing is that you''re afraid of losing data in case the game crashes (though a chat-log doesn''t sound like very critical data). If that''s the case, just make your game more stable .

Whatever the reason you should probably rethink the whole thing anyway. Keep your data in memory and save it as infrequently as you can. Preferably at times where speed isn''t critical, like when loading a new area/level, or when showing some menu, or waiting for some kind of non-realtime user interaction (e.g. during click-through dialog, or similar, if your game has anything like that). I''m sure you can find places in your game where it''s ''safe'' to save. Additionally you can have a time limit and/or size limit for the buffered data and save when one of the limits is reached (though your users are fairly likely to experience glitches and ''stuttering'' graphics when you do).

Share this post


Link to post
Share on other sites
Bah! I guess all those years of good code practive let me slip on that one..


I never even thought about keeping it open the whole time... Is that a logical thing to do?

BTW, its not only chat stuff, but dynamic information thats going to be written to the file anyway... Just, accessing _it_ instead of a memory buffer seems easier...

Do the yay-or-nay on leaving it open sounds like a yay, aye?

~Jesse

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Dwarf with Axe
I never even thought about keeping it open the whole time... Is that a logical thing to do?

Sure.

Though, IMHO you should really reconsider the whole scheme. Why does it seem easier to write the stuff to a file rather than keep it in memory?

Share this post


Link to post
Share on other sites
If there is no reason to persist the information (save it outside the current game) then don''t bother making a text file, as the ppl above have mentioned it is a performance killer. If you want be able to look back on what has been said (like a chat history, saving the last 20 posts or whatever) I would use a vector or list of strings.

Free advice is often worth as much as it costs, remember that before flaming.

Share this post


Link to post
Share on other sites
if accessing using file methods seem easier. then create a simple wrapper that acts like a file. you should not store anything beyond log data in a text file or a saved state. if its data you will read back again every frame, its wasteful and slow.

for instance;

    
CMemFile::Open()
{
valid = 1;
actual_size = START_SIZE;
dataSize=0;
pos=0;
memBuffer = (char*)malloc(START_SIZE);
return SUCCESS;
}

CMemFile::Read(destBuffer, readSize)
{
int i;
for(i=0; i<readSize; i++, pos++)
{
if(pos<dataSize)
destBuffer[i]=memBuffer[pos];
else
break;
}
return i;
}

CMemFile::Write(sourceBuffer, writeSize)
{
int i;
for(i=0; i<writeSize; i++, pos++)
{
if(pos>=actualSize)
{
memBuffer = (char*)realloc(memBuffer, actualSize+START_SIZE);
actualSize+=START_SIZE;
}

destBuffer[i]=memBuffer[pos];
}
if(pos>dataSize)
dataSize=pos;
return i;
}

CMemFile::Close()
{
free(memBuffer);
}



its not perfect and dont check all errors, heck it may not even work (did not test the code). using the vector class (isntead of use alloc/realloc) is probably a good idea (handles memory allocation automagically). also if its just the fprintf/fscanf function that you like. use sprintf and sscanf which can be used with memory buffers.

since text files are about 10KB, you can easily allocate that and keep it in memory writing to disk only if the data needs to be kept after the app is closed.

[edited by - a person on July 16, 2002 8:46:41 PM]

Share this post


Link to post
Share on other sites
If you''re accessing the file every frame keep and you decide to keep the file open throughout, keep in mind that if your program crashes your file will not be saved, i.e. if you don''t call fclose() on the file then you''re screwed. I''m pretty sure flushing the outstream won''t help you there. So, if you''re using the file to keep track of any debugging stuff or anything volatile or important that needs to be saved, regardless of a crash or not you''ve got to open and close whenever you update the file. I don''t think you have to fclose() if you opened the file for reading only.

Other than that you might want to give some more info on what it is you''re trying to do.

------------
- outRider -

Share this post


Link to post
Share on other sites
fflush() sends data in the io buffer to the disk and thus if the app crashes, all data prior to the crash and before the last fflush() call will be on the disk. though calling fflush slows things down since it forces a physical write to the disk even if you only have a few bytes in the IO buffer.

input boxes dont need to be handled as you say, a string object (see STL), vector object (again STL) or just a straight up array with a limit is fine. NO chat app has no input limit. in fact you want to limit chat input since if someone decides to send their life story they could clog everyone else and flood things easily. most apps tend to put the limit at 1024 bytes since most messages and ideas somone types fits into that nicly. longer ideas can be split between messages (ie fill the buffer to 1024, send it, then repeat).

Share this post


Link to post
Share on other sites
This was a hypothetical question originally, because I was really curious... And THANK YOU to everyone so far who has provided input.

outRider is correct, because this happens more than once. I have a log file that I access throughout major functions in the loading process of my game. The main function called is engine.Create(), which in turn calls world.create(), console.create(), player.create(), etc...

Basically, I wanted to start off my world.create() function like so:

  
int CWorld::Create()
{
Log_Open();
if(player.create() == false)
{
Log_Post("Creating player... [ FAILED ]");
Log_Close();
engine.suicide(EXIT_CODE_2);
}
else
Log_Post("Creating player... [ OK ]");

if(console.create() == false)
{
Log_Post("Creating console... [ FAILED ]");
Log_Close();
engine.suicide(EXIT_CODE_3);
}
else
Log_Post("Creating console... [ OK ]");

...
Log_Close();
}


Someone told me that that is bad coding... Now, there''s nothing wrong with the code... Even if I purposly return false in one of the called functions, it still runs fine...


lol and I realize that I should''ve posted some more information regarding my situation.. Sorry.


But originally my friend (who just converted from PHP... Which isn''t really relevant, so I''ll continue) thought of a chat system in which the game could give you messages based upon what you do (this could be from anything like walking into a new room to jumping up and down)... THe main loop would look something like this:

1. Game sends you a message by writing it to a file (optional)
2. Check the message file
3. Process the messages (put them on screen)
4. loop

But now that I think of it, I think I _should_ just tell him that he should just use virtual memory.

~Jesse

Share this post


Link to post
Share on other sites
What you want is an event handling system, and doing that based on files is a very very bad idea. Even if the two functions communicating are in seperate EXEs, this is a very bad idea.


Create a common event manager (look at Java for a good example of how to design this). Any messages generated by a sub-system is added to the event manager (as a linked list, probably), and every frame the different sub-functions can call the event-manager to check what new events are available, and process them..

For things like logging debugging information, etc, fflush() should work fine.

Allan

Share this post


Link to post
Share on other sites
You could also create a callback function that is caled every time there is a message. This way you don''t have to do any polling.

---
Make it work.
Make it fast.

"I’m happy to share what I can, because I’m in it for the love of programming. The Ferraris are just gravy, honest!" --John Carmack: Forward to Graphics Programming Black Book

Share this post


Link to post
Share on other sites
*reads over responses*
*glances at code*
*watches files open/close several times a frame, 800 frames a second*

Errr, well... it''s an 80GB harddrive, it can take a beating. Love is supposed to be painful

------------
aud.vze.com - The Audacious Engine <-- It''s not much, yet. But it''s mine... my own... my preciousssss...
MSN: nmaster42@hotmail.com, AIM: LockePick42, ICQ: 74128155

Share this post


Link to post
Share on other sites