Is the reading/writing to the registry slow?

U

UJ

I have a system that has five programs that all communicate with each other
via Message Queues. Works well. One program is a watchdog that will make
sure the others are up and going. Currently I have it store info it gets
from when the programs check in into a DataSet (XML file). Problem is, that
file now has to be used by other programs to find out version information
(the file is ALWAYS less that 1K.) The record itself is only five fields and
there are five records usually in the dataset.

I'm running into problems with file contention and I was thinking instead of
writing to a file how about if I use the registry? I've tried using Mutexs
and having problems with it. SQL/Database is not an option.

So I wanted to know, is reading/writing to the registry frequently (each
program would write to it every minute, one of the programs would read it
every minute.) problematic?

If I'm doing lots of reading/writing will it do anything to the machine;
i.e. - slow it down, cause problems with the registry, cause problems in
Windows ?

Is the size of the registry an issue ?

TIA - Jeff.
 
B

Bala

Hi,

As far as I know, reading and writing operations against the Windows
Registry are pretty fast!
I would not worry too much about the "Registry size". Especially
because you say that there are only 5 records (each holding 5 fields)
in the dataset. This would boil down to 5 Registry keys with 5 subkey's
each. That should not be a problem!

However, you will be abusing the registry. The registry isn't exactly
designed for holding "process state info" (although it can be used that
way). I do not really understand what you're needing the "file" (or the
registry) for. Why don't you just keep the data you need in memory? You
could use message queues to query for the data, instead of using a file
for this.

Good luck,

Alke Wiebenga



UJ schreef:
 
G

Guest

While I am not so sure that using the Registry as a sort of temporary Data
Store is the best way to solve your issue, no, Registry access is very fast.
In fact, if you download yourself a copy of RegMon and have it running you'll
see all kinds of registry traffic going on in your pc even if you arent'
actually doing anything.
HTH,
Peter
 
M

Marc Gravell

Personally I'd advise you to stick with files and mutexes - it is a very
simple solutions, and should be very portable between environments (if that
ever becomes an issue), plus it avoids all sorts of registry access
permissions / identity issues. You didn't respond to yesterday's question to
explain what these contention issues /were/ (the real symptoms) - care to
elaborate?

Marc
 
U

UJ

I've got a file that is created by a program. Other programs that are
running need to access that file. (This file contains things like what
programs are running, when was the last time we heard from the program, what
version the program is, ....) I tried first doing a mutex but somewhere
along the way something would happen where the mutex wouldn't get released
right. So the other programs couldn't get at the file. Or if they did, they
had to wait for a period of time before they gave up on the mutex and read
the file anyway.

So I took out the mutex and had the originator create the files multiple
times in different directories for the different programs. (It should be
noted that the file is created minute and the programs poll the file every
once in a while.) This seemed to work OK but seems real cumbersome.

I suppose another way to do it would be to use a Message Queue to request
the dataset from the program that is creating it and send it out to
everybody. Everybody else could keep the thing in memory and not even bother
writing it out.

TIA - Jeff.
 
W

Willy Denoyette [MVP]

Such process 'management' tasks are best implemented using System.Management
namespace classes (WMI).
Let the producer (the watchdog) fire an event type
(InstrumentationType.Event) into the WMI subsystem whenever something
changes that is of interest to the consumer(s), let the consumers (the
programs) register an event watcher, no files needed no polling, instant
eventing.

Willy.




| I've got a file that is created by a program. Other programs that are
| running need to access that file. (This file contains things like what
| programs are running, when was the last time we heard from the program,
what
| version the program is, ....) I tried first doing a mutex but somewhere
| along the way something would happen where the mutex wouldn't get released
| right. So the other programs couldn't get at the file. Or if they did,
they
| had to wait for a period of time before they gave up on the mutex and read
| the file anyway.
|
| So I took out the mutex and had the originator create the files multiple
| times in different directories for the different programs. (It should be
| noted that the file is created minute and the programs poll the file every
| once in a while.) This seemed to work OK but seems real cumbersome.
|
| I suppose another way to do it would be to use a Message Queue to request
| the dataset from the program that is creating it and send it out to
| everybody. Everybody else could keep the thing in memory and not even
bother
| writing it out.
|
| TIA - Jeff.
|
| | > Personally I'd advise you to stick with files and mutexes - it is a very
| > simple solutions, and should be very portable between environments (if
| > that ever becomes an issue), plus it avoids all sorts of registry access
| > permissions / identity issues. You didn't respond to yesterday's
question
| > to explain what these contention issues /were/ (the real symptoms) -
care
| > to elaborate?
| >
| > Marc
| >
|
|
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top