Page 3 of 3
Posted: Tue Mar 08, 2005 7:04 am
a2z wrote: counting_pine wrote:
a2z wrote:Well, with Reiser4 the issue is almost irrelevant. Reiser4 is geared for small files from the beginning.
Is the Registry a small file?
Well... yes and no.
No: Registry --in conventional sense-- is a great big blob of file holding stuff in its own weird internal format. But, this is not what am referring to.
Yes: When Reactos is coupled with Reiser4, you you can think of Registry as both a file and as a directory hierarchy. [Just like a Zip file contains various files and folders in it.]
The difference here, in the case of Reiser4, is that you can access --natively-- each Registry record as a small file.
This is how you can have your cake and eat it too.
IOW, I am referring to 'a file can be a folder' metaphor in Reiser4.
I hope this is clearer.
This is like a disk image file, and this would even possible on FAT filesystem. However, it would be better to use files and folders, because it would be slower this way. You just need build a special editor that would interpret the files in the folder a certain way, with an interface similar to the registry editor.
Posted: Tue Mar 08, 2005 12:18 pm
Hrmm i'm not sure why i'm replying, i sure i'm just flaming here?
anyway, a agree with w3seek, i have written a few programs myself, and have learned although using text files is nice and easy, its like going 10 steps forward in allowing people who haven't a clue to messaround with things much easier, and people who know what they're doing going 10 steps back regarding speed and reliability.
that suggestion i made to help reduce the registry growing seemed to be knocked back purely because someoen doesn't agree with anything i say, it was just an idea, that i believe could be used to remove dead information, what other way is there to remove automatically without some indication of how idle it has been? this is how that desktop cleaner in xp works, and disk cleanup, as far as i know, if you can think up a better way to solve the problem that you keep complaining about please say instead of just bashing everyone else down until we all implement riser4 with millions of text files called 'windowmetrics.txt' with lots of data like 'left=45' etc
i'm not saying do it, i was just suggesting an idea for a problem someone mentioned is a bigdownfall of windows, but i haveto ask this question
How does using text files (forget thefact about speed or anything else) reduce old data? its still stored, it would have to be compatiable with current windows so stuff will still get added and not deleted.
i can't help myself now,how exactly is a filesystem far faster than a database loaded into memory?
Posted: Tue Mar 08, 2005 1:47 pm
Stead wrote:Hrmm i'm not sure why i'm replying, i sure i'm just flaming here?
No, you aren't
It's always good to listen to opinions and ideas.
Stead wrote:... that i believe could be used to remove dead information, what other way is there to remove automatically without some indication of how idle it has been?
Unfortunately it can never be guaranteed that registry keys and values aren't used or required anymore. Think of what would happen if let's say a service wiped out all entries that haven't been accessed or changed for n day and you create registry keys yourself using regedit. All the sudden those keys and values would be gone. The only way is using well-written applications and setup programs that keep track of what information they store and provide ways to wipe them out. good applications could create hive files, load them into the registry and unload them, this way the information is only presend when used and since it's stored in separate files the user can simply delete the file. This of course doesn't include registration information for e.g. COM objects, shell extensions, ...
Stead wrote:How does using text files (forget thefact about speed or anything else) reduce old data?
It will be the same amout of data, plus the entire text file in memory so changes can be flushed to disk frequently (which would be using a bunch of memory plus the time saving propably several hundreds of megabytes to the disk when e.g. the first entry in the file got deleted).
Stead wrote:its still stored, it would have to be compatiable with current windows so stuff will still get added and not deleted.
That's the point, if there weren't so many crappy setups and applications the problem wouldn't exist.
Stead wrote:i can't help myself now,how exactly is a filesystem far faster than a database loaded into memory?
i don't think it's possible to compare a file system to a database (latter is usually based on a file system), they're totally different purposes
Registry is not that bad
Posted: Tue Mar 08, 2005 5:29 pm
Did you know that AIX, the 64-bit UNIX by IBM, also contains a registry?
Little files are easy to use in little installments, with little applications, but when you need to configure a distributed, enterprise level application a transaction based database that contains your bootstrap-time and run-time data is necessary.
Posted: Tue Mar 08, 2005 8:06 pm
I'm not convinced that uneeded data in the registry is such an issue here, those that often install programs and mess around with computers generally format things althe time anyway, i know loads of people who have had computers for years and they still seem fine, provided they defrag it and kept stuff out of the startup folders runs well.
Although i just thought, i've seen registry cleaners advertised, i've never tried them, but how do they determine what is to be removed or not?
glad to know opinions are valued in this forum! too many forums of projects these days seem to be full of all yes men, agree with what the developers say, dismiss any ideas from outside the main group of followers
Posted: Tue Mar 08, 2005 9:29 pm
So here is my idea again (a little bit modified and with worse spelling). We have 3 Regestries one for often used keys (let's say once in an hour). That one would be in memory all time. A normal registry. And a regestry for very realy used keys (Let's say once or twice a month). So these keys are stored somewhere, but they slow down nothing. Also this ones can be makred in Regedit so that we can deleate them manually.
Then all keys must have counters, to see how often they have been accessed. Then we can sort them in the file by the times they are used (often used once first), if that's possible I don't know anything about ros's reg. file format.
The counting will take some time, but I think that's less then we get. But what do you think ?
Posted: Tue Mar 08, 2005 11:04 pm
I'm not sure why 3 separate ones would be faster. You'd then still need three copies of your three master copies to insure integrity. The only benefit you'd see is that your system would be able to see its application specific, environment, and class settings quicker. But that is why they sort near the top as it is. Rarely used elements already sort to the bottom because MS located them deeper into the hive. I think this is just re-inventing the wheel in some ways.
Posted: Fri Mar 11, 2005 11:44 pm
Further on this topic:
I have done a little bit of real-life testing on a heavily used
machine (Registry usage was heavy) and here are the values I got
[I used the RegMon utility made by SysInternals people.]
When I run RegMon for 30 minutes (1800 seconds), it collected
a total of 1,603,331 Registry accesses. Further processing the
215 MB log file, here are the results (counts) for each type
Does this look like Registry needs to be an in-memory file, or
IOW, could it not be a purely disk-based one?
Posted: Sat Mar 12, 2005 6:06 pm
One other problem I see for the registry after heavy usage over time is fragmentation. Maybe it could be useful to implement an (idle?) thread that defragments the registry database files (as well as harddisks?)
This defragmentation process should give the following benefits:
1. Free up unused space from the registry database files
2. Check registry for consistency problems
3. Sort entries to get faster access (if this is not done with each access)
4. If possible: Check and mark non-system entries as "deletable"
if the referenced file(s) are not existing (the user can then later decide what he wants to delete)
5. give the computer some work if no one uses it
(ok, forget this point)
Ok this might be a bit offtopic.
Well for the discussion if a text or a binary file should be used. I think the binary form is better (for the sake of speed and size) and thats what ReactOS needs if it will become a real alternative to MS Windows. Who want's a compatible OS thats alot slower? I prefer to let the system manage/maintain the registry for me and to make automatic backups etc. but this function must work under all circumstances. And I don't really belive that some could handle a plain text registry with several hundert MBs that is unsorted. You wouldn't find much in it. Maybe the emergency backup file could be a (compressed) text file that can be imported into the damaged registry. 8)
Posted: Sat Mar 19, 2005 11:45 pm
Well for the discussion if a text or a binary file should be used. I think the binary form is better (for the sake of speed and size) and thats what ReactOS needs if it will become a real alternative to MS Windows. Who want's a compatible OS thats alot slower?
Speed is only good if it is also safe
I'd rather upgrade my hardware to gain that litle bit of extra speed --proided that the underlying structure is safe
I have had too many cases proving that binary Registry is simply not safe.
Posted: Sun Mar 20, 2005 2:44 am
i think the developers seem quite happy with the registry as it is in reactos, at least thats the impression i've got, no need to change one of the few things in windows that works well
What about searches?
Posted: Mon Mar 21, 2005 4:08 pm
I think that there are here good ideas. But i think that one fact to improve in almost everyone of them is that there should be a non-existent key type
This is because if you have a program that every time it launches, looks for a large amount of keys and most of them are deleted (or never have existed), the system would need to parse the whole registry until be sure that it doesn't exist. From top to bottom if it's a sorted-by-use binary registry, or each registry file (for differents times to be accessed).
Another way to make this stuff may be creating different registrys so an application (done for ROS, of course
) would be able to select in which registry has its data stored (different passwords for each registry is a good idea on all of this problem about security?). Or it may be done automatically.
In both cases the registry access system would need to map some keys to the differents files. I mean, the equivalent of the HKLM and HKCU Software\Microsoft\Windows\CurrentVersion (are we going to change this? many apps would run badly, i suppose it's better to make it an alias to our ROS key) would be placed in a OS-file, other very-used apps its own file or it may be shared between differents.
So, if a shareware/demo programs store large amount of useless data, it would only affect when working with some programs (and it may be optimized from time to time). Moreover, ROS would only need to load one registry file (maybe a bit more, for OLEs, CLSID and all of this stuff). The system loading would be faster than into a large registry, that had to be processed then in the background or... NEVER
I had never understood some things about the registry: Why have extensions the same parent as extension types? I think that's wrong, but, well it has a bit of sense. But HAVING the CLSID root mixed between them? Completely wrong, like havis the OS key into the microsoft's key, when they're been modified for hundreds of programs (not only for Microsoft), and the CurrentVersion?
There are many things bad done on the registry. And we have to be compatible
That's our problem. But i'm going out of topic.
I give you these two ideas. You are free to criticize this. I hope we will get something good from all this topic.