On Thursday 16 June 2005 11:20 pm, you wrote:
On Sat, 18 Jun 2005 22:22:56 +0200, Alexandre Julliard wrote:
Actually the current method is probably the fastest for everything except the initial read.
The only reason that the current method is fast is because we're loading the entire registry into memory. As stated in Bugzilla, this is fine for small registries, but the author of the bug has noted wineserver allocated up to 30MB when wine initiates JUST for the registry!
How do you propose to keep track of multiple sources of the registry data? At one time Wine supported system-wide registry files as well as per-user ones, and some people would like to see that again.
Using BerkeleyDB to access the registry would provide the kind of random-access that we need for such a large amount of information
Samba already uses something called 'TDB', and it's been suggested that the two projects could share a case-insensitive-filename layer based on it; could you look into using that?
- It
would also provide us with a quicker and easier way to search through the registry - so we could finally implement the Find feature in wine's regedit without much effort ( Not that it couldn't be done as is, but things would definitely be easier ).
This could only be done at the expense of several times increase in on-disk storage, and would actually not be used very much.
A more useful enhancement would be to support PCRE syntax for find-and-replace, or multiple views of data, or version-control of the registry... in fact, there are Windows programs that do all that, and all they require is a good, stable, quick implementation of the registry calls, which is what Wine provides.