OK, the speed of opening files actually isn't quite what I'm hoping to address here. Perhaps some background will help.
The UMPC device is somewhat resource constrained in terms of processor specification and possibly in terms of disk/controller/southbridge bandwidth. The main observation when the machine is running slowly is that there is often a lot of disk activity, particularly when closing and applications that does not even have data to write at that point in time.
Now I know all too well that small devices can be severely constrained in terms of disk controller bandwidth and have even worked on system code on devices that share northbridge and southbridge for the same function (memory on the same bus as devices being controlled). In these devices there is heavy contention for the bus and although that may not be the case with the UMPC there are some basics that still may be applicable to gaining a more workable experience.
The basics that I am talking about are that you don't max out certain resources in the normal operating mode.
The area that I am focussing on here is reduction of the IO load against the disk since this could possibly effect..
* Timely transfer of data for other operations in progress.
* CPU utilisation.
Even with DMA and Bus Mastering the CPU is still involved in many cases in manipulation of buffers sent that 'appear' in memory and orchestrating transfers so the low performance CPU is a potential real bottleneck here.
The specs of the disk controller and the bus bandwidth of the R2H? Not sure, haven't gone there yet. I'm at the early stages of speculation and often tuning focussed areas can yield faster results than a full understanding of all components.
Now given what I have said the only metric that would yield any form of evidence would be the Disk Queue Length and particularly that the Disk Queue Length sat at a particularly high level in general operation.
We should expect the disk queue length to be higher on a low spec macine anyway with SmartFetch enabled since it is working all the time. The question is really is this an efficient way of working since although loading may be faster once things get cached back, is the interval in between whilst SmartFetch is constantly hitting our constrained resources at the general detriment to the experience.
I will run some tests on queue length with SmartFetch enabled. I anticipate they will be higher than without it enabled but in terms of what I am attempting to convey I feel it proves little since the efficiency of the cache read has to be offset against the level of disk queue.
The only thing that the queue length may suggest is that if it constantly exceeds an unacceptable level then it is a true bottleneck.
Anyway, I will give this a try when I have a little time.
-Andy