.INI Files: Are the "ProfileString" APIs still the best performance choice?

Hi all, wanted to solicit some advice about working with .ini files. Is it still "best practice" to use the "ProfileString" APIs when working with .ini files (e.g., Get/WriteProfileString and Get/WritePrivateProfileString APIs)? Or is there another function/method that has even greater performance that I should be considering? Trying to find the fastest way to basically parse out all the .ini sections/keys and load them into a Treeview control. Thanks for any insight on this, much appreciated.

This is just my two-cents but I haven't used the Get/WritePrivateProfileString API calls in ages. WOW, when was that the way we did things? Win3.1? Or do we have to go all the way back to DOS?

I do often read from and write to one INI file as well as MANY other INI-like files. I suspect the Get/WritePrivateProfileString API calls are still there. (In fact, I just checked and they are.) However, I'm not completely sure I'd trust them. When I massage these types of files, I write my own routines to do so. And, with these small to moderate sized ASCII files, I don't think you'll notice any speed degradation at all.

Also, if these are INI files that you're creating for yourself, keep in mind that these INI files will probably be machine specific, whereas things in the registry could be either machine specific or user specific.

WOW, I just checked my primary application, and I actually do touch about a half-dozen INI files: one related to the SMPlayer I use, one related to some third-party foot pressure software I use, one that's part of the Nuance PDF creator, one involves something I do to Win.INI regarding printers, and even one I created myself for cases when a little MDB database isn't in the same folder as the program. Hmmm, so, I guess, long live INI files.

I can possibly round up some code to read these things, if you like. However, I'd be shocked if there's not some code to do precisely that somewhere in these forums.

Best Of Luck,
Elroy

EDIT: Oh WOW, I lied. I actually do use GetProfileString and WriteProfileString when reading and writing to the Win.ini file. WOW, and that code is used ALL THE TIME, and is apparently incredibly bullet-proof on all versions of WinOS or I would have long ago heard about it. I use it to set/change the default printer.

These were never performance demons.

By nature stream files do not support inserting or deleting things from the beginning or middle. So updates usually end up rewriting the entire file. On top of that the "write" calls lock the file for concurrency management in order to prevent chaos and corruption.

If such files are relatively small and infrequently modified as they were intended to be I don't see any problem though. Even then they should be much better than hammering on the registry and creating fragmentation there. But they are meant to be "read mostly" data with only rare updates, just like the registry.

Those calls can also "spill over" writing/reading registry keys, and in many cases system INI files redirect to the registry.


The alternative is to use some sort of keyed I/O file optimized for concurrent updating. All we have "standard" in Windows like that are Jet Red (Jet 4.0) and Jet Blue (ESE). Jet Red is what VB was born and evolved with, and these are also parasitized by MS Access. ESE is normally used by Windows and by Exchange but little else on a large scale, and seldom used with VB because no OLE DB Provider was ever offered.

You'd normally only use those (or some 3rd party file access method library) if you have far more data than INI files are designed to hold.

The APIS work fine but as mentioned above they are not intended for speed nor any heavy lifting. They are just intended to be used for a configuration file. I use them in most programs, usually they will consist of 2 to 20 lines depending on the program and they are read at startup.

If speed is what you want then either a DB or a RA file. Then again it also depends on how you are wanting to access the data. If you are just going to read it all in and place it in a treeview then a plain old text file might be fine.

Quote:

---

Originally Posted by swambast

Trying to find the fastest way to basically parse out all the .ini sections/keys and load them into a Treeview control.

---

It appears it's actually the TreeView control and not the INI file functions that's the bottleneck.

Attachment 139909

Thanks for the replies and info.

Bonnie, you provided what seems to be a good reference including code, thank you! I recognize some of that code set; believe it might be leveraging VB5 approach at solving this problem. Anyway, despite my best efforts, when I took the INITreeViewer Sub into my test project I never could get it to work. (always failed at the Set oNodes branch for some reason: If SysReAllocStringLen(VarPtr(sBuffer2), , nSize) Then Set oNodes = TreeView1.Nodes Else Exit Sub).

Despite this, are you suggesting from your post that this code set/approach is the fastest way to get the job done of loading up the TreeView? Or was this an example to also demonstrate the Treeview control appears to be more of the bottleneck?

I’m wondering if using a “Get” approach might be better. That is, opening the entire file for Binary Access Read and passing into an array, and then looping through the array basically finding each “[“ using an AscW check to improve processing (e.g., If AscW(curline) = 91 Then Add the current line of the Array which is a section into it’s own separate Array so basically we end up with an array of sections). Thoughts or other ideas and sample code welcome of course!

Quote:

---

Originally Posted by swambast

Anyway, despite my best efforts, when I took the INITreeViewer Sub into my test project I never could get it to work. (always failed at the Set oNodes branch for some reason: If SysReAllocStringLen(VarPtr(sBuffer2), , nSize) Then Set oNodes = TreeView1.Nodes Else Exit Sub).

---

Can you post your code? (or better yet, zip & attach your test project)

Quote:

---

Originally Posted by swambast

Despite this, are you suggesting from your post that this code set/approach is the fastest way to get the job done of loading up the TreeView?

---

That code could probably still be optimized further, but the improvements would likely not be substantial unless a quicker way of populating the TreeView control is found.

Quote:

---

Originally Posted by swambast

Or was this an example to also demonstrate the Treeview control appears to be more of the bottleneck?

---

That example actually does not measure the individual performances of the INI file functions, the VB6 String functions and the comctl32.ocx's TreeView control. I didn't bother timing them because from my experience with that TreeView ActiveX control, I had a strong feeling it wasn't going to be any faster than reading from the disk or processing some strings.

Quote:

---

Originally Posted by swambast

I’m wondering if using a “Get” approach might be better. That is, opening the entire file for Binary Access Read and passing into an array, and then looping through the array basically finding each “[“ using an AscW check to improve processing (e.g., If AscW(curline) = 91 Then Add the current line of the Array which is a section into it’s own separate Array so basically we end up with an array of sections).

---

I believe a pure VB6 approach to reading an INI file probably wouldn't be much faster than calling the INI file APIs. I'd like to be proven wrong, though.

Just as a caveat, I was playing around with some INI files (just because of this thread), and some of the first ones I ran across were Unicode.

They were actually to do with an Oracle server I have installed on my machine.

Just as an example of what you might see in these files:

Quote:

---

[text]
DEVICE_COUNTER_1_001_HELP=عدد الاتصالات الفعلية بالملقمات في الثانية
OBJECT_1_804_HELP=用于 System.Data.OracleClient 的计数器
DEVICE_COUNTER_5_404_HELP=未使用連接共用的連接數目
OBJECT_1_005_HELP=Čítače pro jmenný prostor System.Data.OracleClient
DEVICE_COUNTER_1_005_HELP=Počet skutečných připojení k serverům za sekundu

---

I have no idea if the API INI file reading routines will ready Unicode INI files. I didn't even try.

Just for fun, I took Krool's TreeView and started playing with it. I've also got some Unicode file reading routines, but they don't immediately parse the files into lines, and I wasn't up for improving them just now. Maybe later today.

But anyway, be careful if you think you may run across Unicode INI files. Obviously, some of them are.

Elroy

Quote:

---

Originally Posted by Elroy

I have no idea if the API INI file reading routines will ready Unicode INI files.

---

The W versions of the INI file APIs can read & write Unicode (UTF16-LE) INI files. I'm using the W versions of the INI file APIs in my example above, so that code is Unicode-aware. Unicode text won't display properly though because I'm using the ANSI VB.TextBox control. It apparently is possible, however, for the ComctlLib.TreeView control to show Unicode characters:

Quote:

---

Originally Posted by LaVolpe

2nd. I first came here because I wanted to learn more about creating/using the ListView/Treeview controls via APIs & CreateWindowEx, specifically to support unicode. It turns out, may not have been needed when using v5.8+. Simply setting text via SendMessage vs the VB control's ListItem & Node properties will allow unicode. Of course this means that you'd have to use SendMessage to get/set text properties, but in my case, that is far easier than recreating an entire control or two or three.

---

Why not using XML ? TreeView can be greatly save/load by XML.

> Loaded "C:\Windows\System.ini" in 0.0126 secs.

That is 12 milliseconds for a file that, on my Windows 7 machine, has 12 lines.

Results from a test with a somewhat bigger file:

Code:

---

428 µs for loading "C:\Program Files (x86)\Acer\Welcome Center\fr.ini" with 1230 ini strings
99 µs for finding 55 times "BannerDetail=" in the file

---

That is 500 microseconds, half a millisecond, for loading and parsing a 1000+ lines UNICODE file. So yes, it's the control, not the reading that is the bottleneck.

Search the web for lb_addstring slow LB_INITSTORAGE - maybe you can find the treeview equivalent this way.

Quote:

---

Originally Posted by Bonnie West

That code could probably still be optimized further, but the improvements would likely not be substantial unless a quicker way of populating the TreeView control is found.

---

I agree that populating the Control is the bottleneck here, and would like
to see your Demo adapted to e.g. this "lightweight and virtual TreeList approach" here:
http://www.vbforums.com/showthread.p...TreeList-Demo)

;)

(which would boil down, to filling a "Data-carrying, freestanding ADO-Rs" first)...

Olaf