If you think that's dramatic, the time difference for a giant program like Dopus5 (program, library, 20 modules & 3 support programs) is astounding. After booting from my SFS partition, a "cleanall" on already cleaned sources takes 108.1684 seconds. After adding an FFS directory or partition to the "head" of the path list, a "cleanall" takes 3.1555 seconds. Compiling that program without my path change trick takes so long I have time for a trip to the grocery store before it's done compiling.

Removing APPDIR: does not help (on my system with SFS boot). I am going to re-install FE to a FFS partition and see if it helps. My project takes about 15 minutes for a clean compile. If using FFS with cut it down by 2/3 then it is worth the effort.

mritter0 wrote:Removing APPDIR: does not help (on my system with SFS boot). I am going to re-install FE to a FFS partition and see if it helps. My project takes about 15 minutes for a clean compile. If using FFS with cut it down by 2/3 then it is worth the effort.

I don't think you need to reinstall FE on an FFS partition; you can just copy everything from your SFS System partition to an empty bootable FFS partition. In fact, if you already have an FFS partition, you can use the trick Tony and I are using. Before you compile just enter " path DH2: add head " in a shell (change the DH2: to the device name of you FFS partition). That provides the same speedup as switching to an FFS boot partition. The speed increase will depend on how many files and sub-makefiles your project has. Compiling my current project from an SFS partition without using my "path" trick takes 7.4 minutes. After I enter "path DH6: add head" in a shell, the program compiles in 2.75 minutes.

The default path (as setup by s-s ) now contains appdir: what happens if you remove it?

I've always removed APPDIR: from the default path list in the Startup-Sequence so it can't be having any affect on compile speed on my system. The question is: Why is a directory (APPDIR:) full of text files being added to the default command path in S-S?? AmigaDOS automatically checks APPDIR: if a command isn't found in the path list. I wonder what will happen if a program searches for a command or program in the command paths, finds it in APPDIR: and tries to use LoadSeg() & CreateNewProc() or SystemTagList() to run the command. I don't know if AmigaDOS will recognize that the command is in APPDIR: and run the command from the directory that the textfile in APPDIR: points to or not.

xenic wrote:...The question is: Why is a directory (APPDIR:) full of text files being added to the default command path in S-S??...

APPDIR: is a filesystem, just like RAM: or any other volume, it's not full of "text files", it contains only softlinks.The softlinks are created by the appdir_filesystem from the "text file" data held in the appdir_server's cache.The appdir_server maintains those text data files which are updated when most commands are loaded.

So, the reason APPDIR: is added to the end of the global path is because if something is searching for a commandusing the old style global path search method and the command is not found, at the end of the search it has one extrachance to see if you had it installed somewhere else not in the normal path.This just allows you to have every program you actually used, to be found in a shell or wherever, without havingto specify an actual full dos path for it.

It's also extremely handy for specifying tooltypes and external commands in tools like DirectoryOpus and friends,that way if the path changes for a tool, you don't have to go through the config and change every directory utility,email program, browser, etc... to the new tools path, they can always be found in APPDIR:

colinw wrote:APPDIR: is a filesystem, just like RAM: or any other volume, it's not full of "text files", it contains only softlinks.

O.K. I was wrong because I made the assumption that the files I see in ENVARC:AppDir are the same as the APPDIR: files. When I list the ENVARC:AppDir directory I see text files but when I list APPDIR: I see the files as links. However, my original point was that APPDIR: doesn't appear to be the cause of the "make" command speed difference when booting from an SFS partition as opposed to booting from an FFS partition.

Since we now know that linking from a write-protected (locked) SFS partition doesn't work the same as linking from a write-protected FFS partition, it would be handy for us to be able to "assign" the directory for APPDIR: to use (like APPDIRARC:) for storing the command locations.

mritter0 wrote:I created a FFS (DOS\07) partition and copied everything over and booted from it.....no difference with (or without) using the PATH DH3: ADD HEAD before make'ing my project.

I think you've misunderstood. Compiling is faster if you boot from an FFS partition and slower if you boot from an SFS partition. Using the PATH change just makes compiling when booting from SFS partition as fast as when booting from an FFS partition. Using PATH FFS_PARTITION: ADD HEAD only speeds up compiling if you are booting from and SFS partition.

I am using WinUAE if it matters. I will try some more stuff.

This topic is only relavant to OS4.1FE. It has nothing to do with a PC running WinUAE. Why are you looking for WinUAE answers in an OS4 forum??

I did not misunderstand. I said it made no difference for me booting from FFS or SFS (same compile speed/time). I tried the PATH DH3: ADD HEAD just to see if it would do anything. I am running FE in WinUAE. Just said it in case it was a real hardware issue.