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!
Admittedly it's not very elegant, but it's simple and allows us to store everything in text format.
I'm not saying we should abandon the way we edit our registry - because it is very useful to be able to edit it manually with a text editor. . . HOWEVER, I believe we should have a more elegant way that the API accesses the registry. . Using a small helper app to sync our plain-text registry files into a db format would let us maintain a human-readable format of our registry, while also reducing the overhead required by the current registry format. . .
So I'm not at all convinced that using a real database would be worth the trouble.
Using BerkeleyDB to access the registry would provide the kind of random-access that we need for such a large amount of information - 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 ).
I'm really not trying to push something that wouldn't help wine if not now, in the near future. . . A lot of people don't have fast machines with an abundance of memory. . . 30MB can be a lot of memory for someone with 128MB of RAM. . .
Please consider this further. .
Thanks,
--Brad