Thanx and request

[JDPower]

Could you explain - in small simple steps - everything you do with XP optimization and JKD optimization, and what benefits you achieve in each step? It must be quite good if you can combine the benefits!

Sure. I run the ProcessIdleTasks command:

rundll32.exe advapi32.dll,ProcessIdleTasks

I have it saved in a batch file for ease but can be run via Start>Run. This trims old entries from the prefetch folder and rebuilds the layout.ini (which removes unnecessary entries from that). The down side to this is that it runs a boot file defrag which disrupts JKD's file placement, but as I'm running JKD afterwards that's not a problem. After the ProcessIdleTasks command has finished (usually 5-10 mins, the defrag processes are visible in Task Manager while it is running) I run my monthly sort by name defrag with JKD. This removes most of the boot defrags optimisation but the application prefetch will still be optimised.

[Lundholm]

Sure. I run the ProcessIdleTasks command:

rundll32.exe advapi32.dll,ProcessIdleTasks

I have it saved in a batch file for ease but can be run via Start>Run. This trims old entries from the prefetch folder and rebuilds the layout.ini (which removes unnecessary entries from that). The down side to this is that it runs a boot file defrag which disrupts JKD's file placement, but as I'm running JKD afterwards that's not a problem. After the ProcessIdleTasks command has finished (usually 5-10 mins, the defrag processes are visible in Task Manager while it is running) I run my monthly sort by name defrag with JKD. This removes most of the boot defrags optimisation but the application prefetch will still be optimised.

Hi JDPower

IT seems perfectly clear now what you are doing, and it also seems perfectly clear that there are no benefits from the defrag run.

JkDefrag will overrule ALL of the defrag optimization, which is clearly explained in the documentation. So you will have no prefetch optimization, or whatever you think you get from the defrag.

But this is good! You can completely forget about XP optimization and prefetch and save some time.  

And use sort option 9    :!:  

[Robert_S]

I think he (JDPower) means that he would profit from application prefetching a lot...

But he seems not have tested without.

What´s worth to be prefetched? - Notepad.exe???

Hey man as I said: If app prefetching would pick big apps only I would give it a try but it picks absolutely all even installers which are run only once so it has to be cleaned often - not worth the work!

My apps (and a lot of reaaly big ones) launch very fine.

I think he should try it that way first (without PF) before telling it´s that good.

[Lundholm]

I think he (JDPower) means that he would profit from application prefetching a lot...

True, but everything that XP knows about prefetch becomes obsolete, when you run a JkDefrag sort, because all the files are moved. But XP will (slowly) build new prefetch information after the sort, and use it eventually, until the files are moved again.

Cheers

[jeroen]

everything that XP knows about prefetch becomes obsolete, when you run a JkDefrag sort, because all the files are moved.

I've not yet found documentation about the .pf scenario files in the prefetch folder, so I could be wrong, but I think running JkDefrag (or any other defragger) does not make all the prefetch information obsolete.

I can see filenames in the scenario files, and at least one table of 32-bit numbers. I therefore think they contain a list of blocknumbers relative to the begin of the files. For example, block 7 in file 1, then block 3 in file 2, then block 4 in file 1. Something like that. This information will remain valid when a file is moved to another location on disk.

The scenario files would become obsolete only if they were simply a list of blocks on disk. I don't think this is the case. Files can be moved for any number of reasons, not just by defragmentation. It would frequently cause the prefetcher to do useless work, making the system actually slower instead of faster. I think Microsoft is smarter than that.

[Lundholm]

The scenario files would become obsolete only if they were simply a list of blocks on disk. I don't think this is the case. Files can be moved for any number of reasons, not just by defragmentation. It would frequently cause the prefetcher to do useless work, making the system actually slower instead of faster. I think Microsoft is smarter than that.

Hi Jeroen,

I hope this is correct, but when I read this article, I get the impression that application prefetch is related to the physical location of files and directories in order to minimize seeks:

http://msdn.microsoft.com/msdnmag/issues/01/12/XPKernel/

Very interesting topic. I'll keep you posted, if I come across more detailed information.

Anyway, I think that the current version of JkDefrag optimizes the boot and application startup just as well as or better than XP.

Version 4 will be even better, I suppose, with the possibility of defining an optimized "boot zone". Keep up the good work  

[JDPower]

everything that XP knows about prefetch becomes obsolete, when you run a JkDefrag sort, because all the files are moved.

I've not yet found documentation about the .pf scenario files in the prefetch folder, so I could be wrong, but I think running JkDefrag (or any other defragger) does not make all the prefetch information obsolete.

Correct.

And yes I was referring to JUST the benefits from application prefetch, I know the boot prefetch is disrupted by JKDefrag and stated as much already.

[JDPower]

I hope this is correct, but when I read this article, I get the impression that application prefetch is related to the physical location of files and directories in order to minimize seeks:

http://msdn.microsoft.com/msdnmag/issues/01/12/XPKernel/

That is certainly the case with boot prefetch as boot files are placed next to each other for faster seek times during bootup but not with application prefetch AFAIK. Running the optimisation process manually doesn't touch any files during the defrag involved in that process except the boot files (and trims old prefetch entries + rebuilds layout.ini, which is the part I run it for). If it had to move all application files together on the disk it would be quite clear it was doing so, and take an awful lot longer too.

[jeroen]

when I read this article, I get the impression that application prefetch is related to the physical location of files and directories in order to minimize seeks

Yes, but I don't think the .pf scenario files contain information about physical disk locations. Why would they? That info is readily available from the MFT.

I think the prefetcher works like this. Take for example the loading of a .ini configuration file with a list of textlines. The operating system loads the text lines one by one and interprets and processes them. Without a disk cache the system would have to go to the harddisk for each and every textline. The disk cache buffers this somewhat by loading a (small) block of data from the harddisk into memory, the block that contains the current text line.

The prefetcher extends the disk cache by not just loading 1 block at a time, but by buffering a bigger part of the .ini file, or even the complete .ini file. The data stored in the .pf scenario file tells the prefetcher which part of the .ini file, and other files, will be used when starting an application. It combines this information with the physical location information from the MFT, calculates the optimum sequence, and loads the data from harddisk into the disk cache.

[jeroen]

but not with application prefetch

I agree, I think the build-in Windows defragger only optimizes the boot process, and not applications. This is why I would like to know exactly what information the .pf scenario files contain, because then I could use that information in JkDefrag to optimize the disk by application.

[Lundholm]

Hi,

Here is another good article on prefetch:

http://www.microsoft.com/whdc/driver/kernel/XP_kernel.mspx

Jeroen,

You are right about the logical content of the prefetch files; the physical optimization is done by the disk driver, which makes a lot of sense to me.
However, I don't see how JKD can use the memory management information to improve the defrag process. Sounds great, but how?

Cheers

[Lundholm]

Running the optimisation process manually doesn't touch any files during the defrag involved in that process except the boot files (and trims old prefetch entries + rebuilds layout.ini, which is the part I run it for).

Hi JDPower,

I think that application files are also moved as part of the XP optimization.

The prefetch files and the layout.ini file are relevant only to the XP boot optimization and the memory manager, and not to JKD, so any manual activity here - prior to running JKD - has no effect, I'm afraid.

Cheers

[Robert_S]

...And the benefits from application prefetch are questionable, too (what I tried to say...)

I suggest to try it without app prefetching - the result will be better than expected I think...

Set "EnablePrefetcher" = 0, empty the prefetch folder and do your favorite optimization with JKD an try a while. If you are not pleased you can reactivate it again (you [JDPower] seem to run it only manually, anyway - which is not recommenend...)

For me - since I turned it completely off there is no more background working or such stuff - the pc just runs, and runs, and runs, and runs...

I think that way: Which App needs to be prefetched? If there is one it should take at least 20sec. to launch - then we can talk about it, and even those launch much smoother w/o pf because of the optimized sort of its files by JKD.

So if you don´t test you will see it only in one way.

The time you take to maintain that mechanism and then reorganize it again is senseless - and your HDD has to do all of the work.

[jeroen]

I don't see how JKD can use the memory management information to improve the defrag process. Sounds great, but how?

I could then optimize/place all the files of an application close together on disk. The Windows defragger does not do that, the files used by an application can be spread all over the harddisk.

[Lundholm]

I could then optimize/place all the files of an application close together on disk. The Windows defragger does not do that, the files used by an application can be spread all over the harddisk.

Yes, but this is exactly what the option 9 sorting does. Files that are used at exactly the same time, will be placed next to each other during the sorting.
It is very difficult to improve this sorting (thank you)

...and what would you do, if a file was shared by several applications?
 
Cheers