On 10/20/11 1:10 PM, David H. Lipman wrote:
> It's not many pennies on the dollar and its not the size of the Registry. Think about the
> time differential of the two comparisons. The length of the walk to go direct to the
> product vs. going up and down aisles. Any change in the time that one may consider a
> delay is is a mere fraction.
But it depends on how you get to that product. Travel up the aisle in
an F-16 Tomcat (some quad core high speed CPU), yea, no time at all.
Now, do it in a wheelchair (single core, old slow, by today's standards,
and it does feel slow.
I like James D Andrews post, about Google Earth leaving behind 5,000
left behind. If there were just 6,000 entries to begin with, it really
doesn't matter whether the user sees the effects or not, it still has to
take more time to get to that point. No matter what, the system has to
know *where* in the aisle the product is.
> When the system is booting you have a lot more going on that reading a binary tree. You
> are loading stubs (your old TSRs) and NT Services. You are loading the server of services
> and they have dependencies. All are executables that require the loading of DLLs. All
> are disk files that reside on the disk which is secondatry storage and not primary storage
> and since the OS hasn't cached data, the longest time is evident. How those files are
> accessed will have a greater impact on the time the OS takes to effectuate a boot than the
> loading the Registry into RAM and then reading brancches and leaf nodes of a binary tree.
I don't disagree at all, but the more crap you have to deal with, in
total, the longer it will take. Each little piece adds to that time.
At the moment, the larger discussion here is just one little piece of
crap, excess registry entries. Of and by itself, it doesn't make much
difference, except in James's case.
But I strive to remove *all* the little pieces of unneeded crap,
anything the user of the computer doesn't require to make the computer
function to the max. When you consider the additive effect of all those
little pieces, plus a slow computer, it has to boot faster.
> I love analogies so here is another...
An analogy is a wonderful teaching tool. I always try to use an analogy
the listener understands to explain the general operation of some
specific computer feature. Once the listener has that figured out, they
tend to go gangbusters for awhile.
> I always equate disk defragmentation to reading a newspaper. When one reads an article on
> page 1 you'll find that you'll read a few paragraphs and it tells you to go to page 23.
> You'll read a few more paragraphs and it tells you to go to page 12. You'll read a few
> more paragraphs and it tells you to go to page 30. Wouldn't it be nice if it was one
> contiguous article on page 1 ?
> In the analogy every time the reader has to thumb from page to page and find the article
> there is introduced latency. That latency can be considerable and if the article is
> broken up into many sub parts that considerable latency builds up. By making the article
> contiguous one can read through that article much faster. The same goes when data is
> fragmented on the hard disk. Thus one will get more of an improvement in loading the OS
> by making sure the OS is not being affected by fragmented secondary storage.
I see the same type of issue with modern online help systems. You can
spend so frickin' much time trying to make sense out of a system, you
never find what you are looking for. And if you don't use a search term
that is used by the help system, or in the help documentation, you won't
find a thing.
> My final stateemnt on the boot time is WHAT is being loaded and in what order. More often
> then not, the "used" computer will load numerous items from various locations from NT
> Services to HKLM/HKCU Run location, programs\startup, etc. One has to manage these items.
> Everything from the Machine Debug Manager service to video TSRs to QuickTime's stub, etc.
> Optimize the hard disk, optimize what is loaded upon boot and one will see much greater
> gains than try to 'F' with the Registry.
Which is why optimizing the hard disk is the last, or almost the last,
thing I do before giving the computer back to the owner.
In all honesty, I don't think we are on different pages, I just work on
Model T's most of the time, and you do notice the effect of the "little"
Mac OS X 10.6.8