win32 api WritePrivateProfileStringW so slow??
Author
Hi,
Recently I'm writing a flag manage tool for our game. I want to save all my flags info into a ini file, but I found these win32 functions works so slow.
my code look like this
for(int i=0;i<300;i++)
{
WritePrivateProfileStringW(...);
WritePrivateProfileStruct(...);
....//5 or 6 more
}
but this cost about 3 seconds, is there any way to solve this??
hope I make myself understood , thanks for any help.
You're doing 2400 writes. If that takes 3 seconds, that's an average of 1.25ms per write, which is perfectly possible if it's opening a file handle, writing and then closing it.
Is there any reason you're not using the registry, as recommended?
Is there any reason you're not using the registry, as recommended?
Quote:Isn't the registry also more or less deprecated?
Nope, Vista still uses it. I doubt it will be going anywhere anytime soon. Remember the registry is just a file at the end of the day.
Stop! Drop! and roll!
If performance is a problem, then don't even think about using registry. Registry is fine for some reading and accessing some persistent properties.
But if you run into a situations where access becomes a problem (2400 writes in 3 seconds), then you've just abused the system.
Use XML instead.
While certain parts of registry are ran from memory (possible all), it's not intended as random access media, or anything that requires some extensive updates.
I have an application on notebook (related to modem) which spams the registry some 10 times every second. It's horrible. Horrible.
As such, if performance ever becomes a problem - you're using wrong media. I'd consider any application that abuses registry in such a way malware.
If performance is a problem, then don't even think about using registry. Registry is fine for some reading and accessing some persistent properties.
But if you run into a situations where access becomes a problem (2400 writes in 3 seconds), then you've just abused the system.
Use XML instead.
While certain parts of registry are ran from memory (possible all), it's not intended as random access media, or anything that requires some extensive updates.
I have an application on notebook (related to modem) which spams the registry some 10 times every second. It's horrible. Horrible.
As such, if performance ever becomes a problem - you're using wrong media. I'd consider any application that abuses registry in such a way malware.
If you are developing for Vista then you shouldn't be writing stuff to the registry unless there is a very good reason for it.
WritePrivateProfileWhatever is not optimized for zillions of little writes. Think about it - for each call it needs to open the file (slow), dink around trying to figure out where in the file the section you care about is (slow), and possibly insert data into the middle of the file (really slow).
The registry will probably be a little better. However again it's not optimized for zillions of little pieces of data. Unless you only have a little bit of data the registry is usually best left to holding the path and filename of your real config file.
You want to write out all your configuration data at once yourself (possibly with the aid of some generic serialization library if you have one). The format you write your data in is mostly irrelevant to the original question. XML may make sense or it may not. You could also write it in .ini format or even a binary format.
The registry will probably be a little better. However again it's not optimized for zillions of little pieces of data. Unless you only have a little bit of data the registry is usually best left to holding the path and filename of your real config file.
You want to write out all your configuration data at once yourself (possibly with the aid of some generic serialization library if you have one). The format you write your data in is mostly irrelevant to the original question. XML may make sense or it may not. You could also write it in .ini format or even a binary format.
Quote:Original post by cmptrgear
If you are developing for Vista then you shouldn't be writing stuff to the registry unless there is a very good reason for it.
That's slightly correct. What you meant to say was
"If you are developing for Vista then you shouldnt be writing stuff to HKEY_LOCAL_MACHINE unless there is a very good reason for it."
HKEY_CURRENT_USER is always open for your apps to write to and is a great place for storing settings.
I think you should definitely use a binary file in this case.
1. You know exactly how many times you need to read/write (300), which will make binary file a breeze to read/write
2. You are already storing structs with binary data (WritePrivateProfileStruct), might as well do it in a binary file.
3. You are reading and writing the whole thing top-to-bottom, without any jumps, which will make it an extremely easy to read/write binary file.
To read/write strings, just prefix a string with an int that will contain its length. To write a string, write an int for length followed by the string itself. To read a string, read an int, allocate string of that size + null char, then read the number of characters based on length. Don't forget to multiply string length by sizeof(WCHAR) when passing the size to write/size to read to the file functions, because they expect byte sizes, and your strings take 2 bytes per character.
1. You know exactly how many times you need to read/write (300), which will make binary file a breeze to read/write
2. You are already storing structs with binary data (WritePrivateProfileStruct), might as well do it in a binary file.
3. You are reading and writing the whole thing top-to-bottom, without any jumps, which will make it an extremely easy to read/write binary file.
To read/write strings, just prefix a string with an int that will contain its length. To write a string, write an int for length followed by the string itself. To read a string, read an int, allocate string of that size + null char, then read the number of characters based on length. Don't forget to multiply string length by sizeof(WCHAR) when passing the size to write/size to read to the file functions, because they expect byte sizes, and your strings take 2 bytes per character.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
