Re: Reg/INI Discussion from much earlier

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Ralph (nt_consulting32_at_hotmail.com)
Date: 07/28/04 

Date: Wed, 28 Jul 2004 08:43:51 -0500

"J French" <erewhon@nowhere.com> wrote in message
news:41073b42.82740566@news.btclick.com...
> On Tue, 27 Jul 2004 13:58:20 GMT, "Wes Spikes"
> <MornThdr@NOSPAMverizon.net> wrote:
>
> >Thread I'm commenting on is "Re: Best practice for saving information
> >between runs?"
> >
> >OK, Sorry to be coming in late. First, I must note that I'm using Outlook
> >Express to read this and I cannot read the entire thread. (I'm going to
go
> >to Google later and read it all), but for now, this is my openion on the
> >Reg/INI question. Do NOT take my openion facto because I am open to
> >suggestions.
> >
> >Save everything into the regestry it's faster. But one must also note
that
> >in the event of an improper shutdown, the registry is NOT saved. This may
be
> >good if an app setting that the user has changed is causing it to crash
on
> >load, but also may be bad if it is caused by a power outage or some other
> >uncontrolable factor and the user wants to save his/her settings.
Therefore,
> >I believe that it may just be best to save 2 copies. One to an INI (or
any
> >other file for that matter [binary or text alike]) and one copy to the
> >registry. For the first value in the INI file, put the date/time the
> >settings were saved. And save that same date/time into the registry. If
> >there is an improper shutdown, then those two dates will differ, and, on
> >your app's load, you can prompt the user for which settings to use.
> >
> >I'm very open to suggestions and am looking forward to hearing them.
>
> I agree with the 'belt and braces' approach
> There are some interesting developments from that
>
> I am a bit lost about the reasoning though.
> Using both the Registry and the INI file has got to be /slower/ than
> just using one of them
>

Not sure I follow that reasoning. Both devices use very different portions
of the 'system', (File I/O and System Pooled Memory) so it is hard to see
how using one would impact one or have a combined effect with the other.

>
> Personally I am deeply suspicious of the PrivateProfile APIs
> I suspect that they are very inefficient, and prefer to use my own INI
> Class - so I simply have one File Open Read Close at the start of the
> App, and from then on have the INI entirely in memory
>

The PrivateProfile APIs use a "behind the scenes" optimization for caching
file access. Subsequent reads within a specified time interval do not reopen
the file, but read the cached file. Opening a file, or memory mapping, on
your own would certainly mimic this behavior, but wastes a file, and
theoretically "locks up" some memory and a system resource. But practically
would be negligible in the grand scheme of things.

The API calls do have an advantage when it comes to writes, as it will
automatically write out changes to the disk (after the time interval
~2secs), and sets dirty bits on modified values. If creating your own
handler you have to manage this on your own.

Writing your own INI file management does have the advantage of addressing
some limitations of the API managing an .INI file - that of being only
text-based, 256 character limit for values, and preserving comments.
However, if this was a concern I would consider using the new XML ini
formats.

>
> Under 16 bit Windows I snooped on INI file activity with my own 16 bit
> version of FileMon that dumped all file activity to the printer
> - the printer was screaming
> I should really do a similar test with FileMon
>

I suspect when you were dumping activity to the printer - you were in effect
over-riding the "caching" ability of the API INI calls. If using FileMon,
you will also have to take in account the effect of the instrumentation of
measuring on what it is you are measuring.

-ralph

Quantcast