What is a Compaction Thread?

[Jon Westfall]

<div class='os_post_top_link'><a href='http://blogs.msdn.com/windowsmobile/archive/2006/03/16/552996.aspx' target='_blank'>http://blogs.msdn.com/windowsmobile.../16/552996.aspx</a><br /><br /></div><i>"I've received a few questions from users who have said that their WM5 device seems to slow down and speed up erratically. Some have dug in and found that "filesys.exe" is using a lot of CPU power and that it appears to be running something called a "Compaction Thread." There have also been questions about a registry key called CompactionPrio256. I can't explain some of the bigger problems people are describing, but I can at least tell you what these things are and what they're trying to do."</i><br /><br />A bit of elightenment on File System operations and the mysterious Compaction Thread. Couple this with <a href="http://blogs.msdn.com/windowsmobile/archive/2006/03/16/553042.aspx"> this article </a> for all you ever wanted to know about speeding up file system operations, and more!

[Nurhisham Hussein]

That second article was especially interesting - now I know why all installed programs are placed in the root directory of a flash card. Having them in a nicely organised Programs folder will slow execution times.

[phreaker18]

very interesting reading.............

[jgrnt1]

Interesting....I may reconsider whether I want to upgrade my iPAQ 4700 to WM5. I don't have any RAM shortage problems, so if my device is faster because user data is stored in RAM when running WM2003SE and the WM5 upgrade will change this, I need to look carefully at the benefits of WM5 to see if the upgrade is worth doing.

[badbob001]

That second article was especially interesting - now I know why all installed programs are placed in the root directory of a flash card. Having them in a nicely organised Programs folder will slow execution times.

From my experience, at least on WM5, when I pick to install an app on the storage card, it goes under \storage card\program files\ and not the root.

Also, I don't think it will hurt performance if you install all your programs under the \Program Files\ folder as long as each program is in its own subfolder. If you like to collect lots of single-file utilities and put them all under \Program Files\, then that may slow things down a bit when accessing that folder.

[Nurhisham Hussein]

From my experience, at least on WM5, when I pick to install an app on the storage card, it goes under \storage card\program files\ and not the root.

I use File Dialog Changer and Cabinstl to stuff all my program folders and files into a Program Files directory - this is under WM2003SE. The default behaviour for this and other older OS's is to install apps in the root directory.

I might go back to the default location after this - I have noticed a slowdown in program launches.


Also, I don't think it will hurt performance if you install all your programs under the \Program Files\ folder as long as each program is in its own subfolder. If you like to collect lots of single-file utilities and put them all under \Program Files\, then that may slow things down a bit when accessing that folder.

The following quote implies that a sub-directory structure will impede performance:

If your program requires all the files be stored in one directory, perhaps you can write a file system filter that will hide the subdirectories for you.

[badbob001]

I use File Dialog Changer and Cabinstl to stuff all my program folders and files into a Program Files directory - this is under WM2003SE. The default behaviour for this and other older OS's is to install apps in the root directory.

I use WM5 now so I've stopped using cabinstl. When I was using cabinst, one annoying thing was that if you change the install location, you have to create the subfolder for the program manually. So say I wanted to install acrobat on \storage card\program files\, I would need to create a acrobat folder and then select that in cabinstl.

If you're installing everything in \program files\, wouldn't programs that use files with the same name overwrite each other?

The following quote implies that a sub-directory structure will impede performance:

If your program requires all the files be stored in one directory, perhaps you can write a file system filter that will hide the subdirectories for you.

If you look at the article, you'll see that the title of each subsection is what TO DO to improve performance:
- Know your block size
- Memory Mapped files for caching
- Use sub-directories (FATFS)
- Expensive APIS: ...

So the author wants you to use sub-directories. The quote above is saying that if your program needs to see all 15,000 files in the same directory, then you can speed it up by hiding the sub-directories, assuming there are subdirectories and that the program doesn't need the the subdirectories to work. This would be important if you have 10,000 subdirectories.

[Atticus]

Sad, sad. He specifically mentions the Dell Axim in his posting. My condolences to all Dell Axim owners. Wait .... I have one myself!

Why, oh why had HTC to screw this one up? All the other PDAs run fine, but the Axims suffer from the compaction thread hogging the CPU.

And why is Dell letting its customers down?

Rhetorical questions, of course. The reasons are obvious.

[Nurhisham Hussein]

When I was using cabinst, one annoying thing was that if you change the install location, you have to create the subfolder for the program manually.

That's where FDC comes in - you don't need to anymore. The correct folders and sub-folders are automatically created, just as if you were installing to the default location.


If you're installing everything in \program files\, wouldn't programs that use files with the same name overwrite each other?

See above.


So the author wants you to use sub-directories. The quote above is saying that if your program needs to see all 15,000 files in the same directory, then you can speed it up by hiding the sub-directories, assuming there are subdirectories and that the program doesn't need the the subdirectories to work. This would be important if you have 10,000 subdirectories.

Good point.

[Kt3]

I don't understand why filesys.exe can't do the work a little bit at a time instead of waiting until it has a lot of work to do. What is it about flash memory exactly that forces the file system driver on our iPaq's to que up a lot of rewrites and then, all at once, uses up 90% - 100% of the CPU to run through the compaction? Why can't Microsoft run the thread on a lower priority, restrict it's CPU usage or like I said, have it compact the memory a little at a time?

[Jason Lee]

I don't understand why filesys.exe can't do the work a little bit at a time instead of waiting until it has a lot of work to do. What is it about flash memory exactly that forces the file system driver on our iPaq's to que up a lot of rewrites and then, all at once, uses up 90% - 100% of the CPU to run through the compaction? Why can't Microsoft run the thread on a lower priority, restrict it's CPU usage or like I said, have it compact the memory a little at a time?

The only reason they fo this is to minimize the writes to the flash memory. You can only write to a block of flash memory so many times before it is worn out. So by writing a little bit at a time as you suggest would completely defeat the purpose. I'd rather have a bit of lag from time to time than have bad flash blocks start poping up from over use.
There are a lot of little things like this that we are gonna have to get used to with the drastic changes that WM5 brings. Over all I think it is a good change. The fear of loosing all my data from a spontaneous hard reset or a flat battery are gone.

:) I hope. hehehe