Universal Search Subtleties -- Observations & Musings (Performance on Restart)

I use Universal Search on the home screen of my 9650. I've also set a password and enabled encryption. I only mention that, because it could have a bearing on the Universal Search performance peculiarities I'm about to describe.

The Universal Search on my BlackBerry 6 Bold performs best if I use the following reboot protocol after a battery pull or soft (alt+right shift+delete) reset:

1. Wait for the screen to shut off after the security tests have passed.
2. Wait ten minutes before doing anything.
3. Enter my password and select "No" for the SIM card option after my Bold unlocks.
4. Wait an additional ten minutes before doing anything else.

I find that if I try to do things too soon after a restart, the Blackberry hasn't finished "indexing," or cataloging things, and the production of search results (in addition to immediate performance) will be impaired. If I start to type too soon, it will even tell me this with a fine print message near the search bar: "Indexing ... search results may be incomplete." And indeed it's true. All of the results I've come to expect during routine searching of my handheld's features do not appear when I try to skip my reset protocol and get started too soon.

What I've described up until now is what I would consider normal performance for my BlackBerry, its os, its specs, and security configurations. An anomaly shows up if I change my security timeout to five minutes. If I apply the five minute security timeout, I've noticed that Universal Search will forever return incomplete results, even if I follow my 20-minute startup protocol. With the five minute timeout, the BlackBerry could sit even overnight, and no amount of waiting will result in complete search results. It's like the indexing has been interrupted and is forever incomplete.

One of the things I type often is "status." Usually I don't even type "status," I just start to type "sta," and the Options wrench with three choices shows up as a clickable search result. When I click on the resultant Options wrench, three choices should show: Security Status Information, Voice Dialing Settings, and Device and Status Information. Device and Status Information is the one I'm looking for; that's where I check my battery level. (I can get to that by typing "battery" also, but I'm simply accustomed to typing "status.") When the indexing anomaly has occurred and the search results are incomplete, the one I'm looking for is, of course, not there.

Here's my workaround: if I'm using the five minute security timeout, I'll change it to something else before rebooting. I haven't tested a lot of the other options, but I haven't had any incomplete indexing issues (when following my restart protocol) while using the one minute or the one hour security timeouts.

None of what I've described (even the anomaly) is, in my opinion, a bug or other flaw in the os. I think the need for my startup protocol is normal, the anomaly is a fluke resulting from some process being interrupted in the moment my handheld locks upon the first five minute timeout, and all of it is directly connected to the combination of my processor's specs, my security configurations (encryption and timeout setting) in place at the given times, and whatever the handheld is supposed to be doing during and immediately following a restart. When I watched the CrackBerry unboxing video of the Bold 9900, one of the things I noticed right away was that the 9900 booted up very fast. Then there was the part, not long thereafter, where he typed "memory" to see the device's specs. He didn't follow my startup protocol and wait twenty minutes. The 9900 returned the appropriate result right away. Why? Its processor is a lot faster than that of my 9650. He also didn't have any security settings applied with the device fresh out of the box. The processor is, of course, the more significant factor.