The Price of DuplicateHandle

I'm writing a class library that provides convenient object-oriented frontends to the C API that is the Windows Registry. I'm curious, however, what the best course of action is for handling HREGs, for instances where my key class is copied.

I can either

1. Allocate a heap integer and use it as a reference count. Call RegCloseKey() on the handle and deallocate the integer when the refrence count equals zero.
2. Use the builtin functionality of handles, and rather than开发者_开发知识库 maintaining a reference count, call DuplicateHandle() on the HREG when the registry key object is copied. Then always call RegCloseKey in destructors.

The DuplicateHandle() design is much simpler, but I'm concerned if designing things that way is going to severely hamper performance of the application. Because my application recurses through hundreds of thousands of keys, speed of copying this object is a sensitive issue.

What are the inherent overheads of the DuplicateHandle() function?

I suspect you'll find that DuplicateHandle has very little overhead. The kernel already manages a reference count for each open object, and DuplicateHandle adds a new entry to the kernel handle table for the destination process, and increments the object reference count. (DuplicateHandle also normally does security checks, although it may skip that if the source and destination processes are the same.)

You may run into difficulties if you open hundreds of thousands of objects at the same time, depending on how many handles Windows feels like letting you open.

I've never encountered any implication that DuplicateHandle() has unexpected overhead.

I suspect a few science experiments are in order to confirm that. Be sure to do that on several platforms, as that is the kind of thing Microsoft might alter without warning.