SDK:C/make very slow with OS4.1FE (SOLVED)

Have a question about our Software Developer Kit? Ask them here.
xenic
Posts: 1185
Joined: Sun Jun 19, 2011 12:06 am

Re: SDK:C/make very slow with OS4.1FE

Post by xenic »

tonyw wrote:That is bloody dramatic !!
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.
I'll bring this thread to Colin's attention.

Bug #9268 submitted.
Thanks! Hopefully the problem can be found and fixed.
AmigaOne X1000 with 2GB memory - OS4.1 FE
User avatar
broadblues
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 600
Joined: Sat Jun 18, 2011 2:40 am
Location: Portsmouth, UK
Contact:

Re: SDK:C/make very slow with OS4.1FE

Post by broadblues »

random thought on this.

The default path (as setup by s-s ) now contains appdir: what happens if you remove it?
User avatar
mritter0
Posts: 214
Joined: Mon Aug 25, 2014 9:41 pm
Location: Bettendorf, IA, USA

Re: SDK:C/make very slow with OS4.1FE

Post by mritter0 »

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.

Hopefully fixed soon.

BTW, are there any plans to update the GCC port to a newer version?
Workbench Explorer - A better way to browse drawers
xenic
Posts: 1185
Joined: Sun Jun 19, 2011 12:06 am

Re: SDK:C/make very slow with OS4.1FE

Post by xenic »

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.
AmigaOne X1000 with 2GB memory - OS4.1 FE
xenic
Posts: 1185
Joined: Sun Jun 19, 2011 12:06 am

Re: SDK:C/make very slow with OS4.1FE

Post by xenic »

broadblues wrote:random thought on this.

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.
AmigaOne X1000 with 2GB memory - OS4.1 FE
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 207
Joined: Mon Aug 15, 2011 9:20 am
Location: Brisbane, QLD. Australia.

Re: SDK:C/make very slow with OS4.1FE

Post by colinw »

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 command
using the old style global path search method and the command is not found, at the end of the search it has one extra
chance 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 having
to 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:
xenic
Posts: 1185
Joined: Sun Jun 19, 2011 12:06 am

Re: SDK:C/make very slow with OS4.1FE

Post by xenic »

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.

Sorry for the misinformation about the APPDIR: contents.
AmigaOne X1000 with 2GB memory - OS4.1 FE
User avatar
mritter0
Posts: 214
Joined: Mon Aug 25, 2014 9:41 pm
Location: Bettendorf, IA, USA

Re: SDK:C/make very slow with OS4.1FE

Post by mritter0 »

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 am using WinUAE if it matters. I will try some more stuff.
Workbench Explorer - A better way to browse drawers
xenic
Posts: 1185
Joined: Sun Jun 19, 2011 12:06 am

Re: SDK:C/make very slow with OS4.1FE

Post by xenic »

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??
AmigaOne X1000 with 2GB memory - OS4.1 FE
User avatar
mritter0
Posts: 214
Joined: Mon Aug 25, 2014 9:41 pm
Location: Bettendorf, IA, USA

Re: SDK:C/make very slow with OS4.1FE

Post by mritter0 »

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.
Workbench Explorer - A better way to browse drawers
Post Reply