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

[xenic]

Isn't this related to running 4.1 FE on an SFS partition in general? Not only related to make.

Yes but since it only seems to manifest itself in make, the only solution I can think of is for someone to add a lot of debug output to the make sources to determine which system function or component is causing the slowdown.

[ssolie]

There is nothing wrong with GNU make that I know of so no, there is no fix coming in make.

When I compiled the older version of make from the sources that were included with my original OS4.0 prerelease CD, it didn't exhibit the slowdown problem. The current version of make doesn't have a slowdown problem when used with OS4.1u6. The slowdown only occurs with OS4.1FE which indicates that something that was changed for OS4.1FE is affecting make and causing it to slow down when the system is booted from an SFS partition. If you aren't interrested in finding the source of the problem, I'll just keep using my "path change" trick and continue to wonder what else in the system is being affected like make is.

The problem is in dos.library or some other OS component so I am not going to spend any time messing with GNU make to work around it. I have enough to do.

[kas1e]

@ssolie

The problem is in dos.library or some other OS component so I am not going to spend any time messing with GNU make to work around it. I have enough to do.

But somebody still should spend time for fix it

@Xenic
Btw, probably we (i can help with) can ourselfs build "make" with lot o debug to find out what going wrong. Sure, not our business, but probably ppls in charge will apprecate when we can point out on what exactly wrong.

[xenic]

@kas1e
I think ssolie is right; the source of the problem is probably in dos.library and the best we could hope for by changing "make" is a workaround. Since I've already discovered a workaround by making a change to the command paths, it will probably be up to colinw to determine the cause.

[ssolie]

I think ssolie is right; the source of the problem is probably in dos.library and the best we could hope for by changing "make" is a workaround. Since I've already discovered a workaround by making a change to the command paths, it will probably be up to colinw to determine the cause.

I think this is a potentially serious problem with dos.library (or something) which needs fixing because it affects the entire system.

[colinw]

Don't be so fast to blame dos.library yet, it's a very very thin layer for most functions that basically
just forward the DOS API calls to the underlying filesystem, in just a few lines of code.

No-one has yet demonstrated a single DOS function that exhibits anything but a few microseconds of
difference between the "good" and "bad" test setup, much of which can be explained by normal task loading variance.
I am even considering wierd effects like priority inversion between handler processes, due to the fact this manifests
itself only when a DosPacket based FFS lock is added to the shell path, but not any other time.

The second thing to consider is that very few things access the shell path list except a shell process itself,
the shell-handler the workbench.library, and maybe a couple of utilities (like amidock).
As far as DOS is concerned, no dos.library subsystem accesses the path list of any shell.
The only time the path list is even touched inside dos.library is when it is copied for someone calling
CreateNewProc() or starting up a new shell process. After that it is not touched again.

No filesystems have access to the shell path list because, for a start, they don't even have a CLI attached to the
filesystem's handler process, so there's nowhere to inherit a pathlist from, nor is there any reason to access it.

Also, seeing this doesn't appear to affect anything but one command running in a shell, I would be reluctant to jump
to any sort of conclusions, until we have a better idea of what inside that command actually triggers the effect.

[tonyw]

Trying to blame this on dos is proving difficult. I just went back through many old versions of dos (back as far as 53.112) and they all exhibit the same behaviour (ie removing the FFS volume from the Path slows down a big Make).

I don't have a known original Update6 here to test. Can someone tell me the dos version in Update 6 ?

[xenic]

Also, seeing this doesn't appear to affect anything but one command running in a shell, I would be reluctant to jump to any sort of conclusions, until we have a better idea of what inside that command actually triggers the effect.

Maybe you could get that better idea by obtaining the make sources from ssolie.

I have a simple test makefile that doesn't use any SDK commands (other than make itself) which demonstrates the problem quite well:

Code: Select all

#Test makefile

all: dodelete

.PHONY : dodelete
dodelete:
   @echo testing >ram:test.xyz
   @delete ram:test.#?
   @echo testing >ram:test.xyz
   @delete ram:test.#?
   @echo testing >ram:test.xyz
   @delete ram:test.#?
   @echo testing >ram:test.xyz
   @delete ram:test.#?
   @echo testing >ram:test.xyz
   @delete ram:test.#?
   @echo testing >ram:test.xyz
   @delete ram:test.#?
   @echo testing >ram:test.xyz
   @delete ram:test.#?
   @echo testing >ram:test.xyz
   @delete ram:test.#?
   @echo testing >ram:test.xyz
   @delete ram:test.#?
   @echo testing >ram:test.xyz
   @delete ram:test.#?


When I run the above makefile with the make command after booting from an SFS partition it takes 10.2088 seconds to complete (using the timer command from os4depot - e.g. timer make).

When I enter "path Workbench:C add head" (Workbench is an FFS partition) after booting from an SFS partition but before running the above makefile with the make command; the make command takes 0.1670 seconds to complete.

Testing with the above makefile seems to indicate that the problem with make involves executing commands and not the gcc compiler commands themselves. The time difference is obviously a lot more than a few microseconds per command.

[xenic]

Trying to blame this on dos is proving difficult. I just went back through many old versions of dos (back as far as 53.112) and they all exhibit the same behaviour (ie removing the FFS volume from the Path slows down a big Make).

I don't have a known original Update6 here to test. Can someone tell me the dos version in Update 6 ?

My update6 dos library version is 53.156. I think I already tried using the update 6 dos library in FE with no change but you can try for yourself if you want.

[ssolie]

Also, seeing this doesn't appear to affect anything but one command running in a shell, I would be reluctant to jump to any sort of conclusions, until we have a better idea of what inside that command actually triggers the effect.

Maybe you could get that better idea by obtaining the make sources from ssolie.

The GPL source code is included with every SDK so no need to bother me.