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.duga wrote:Isn't this related to running 4.1 FE on an SFS partition in general? Not only related to make.
SDK:C/make very slow with OS4.1FE (SOLVED)
Re: SDK:C/make very slow with OS4.1FE
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: SDK:C/make very slow with OS4.1FE
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.xenic wrote: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.ssolie wrote: There is nothing wrong with GNU make that I know of so no, there is no fix coming in make.
ExecSG Team Lead
Re: SDK:C/make very slow with OS4.1FE
@ssolie
@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.
But somebody still should spend time for fix itThe 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.
@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.
Re: SDK:C/make very slow with OS4.1FE
@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.
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.
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: SDK:C/make very slow with OS4.1FE
I think this is a potentially serious problem with dos.library (or something) which needs fixing because it affects the entire system.xenic wrote: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.
ExecSG Team Lead
- colinw
- 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
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.
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
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: SDK:C/make very slow with OS4.1FE
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 ?
I don't have a known original Update6 here to test. Can someone tell me the dos version in Update 6 ?
cheers
tony
tony
Re: SDK:C/make very slow with OS4.1FE
Maybe you could get that better idea by obtaining the make sources from ssolie.colinw wrote: 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.
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 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.
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: SDK:C/make very slow with OS4.1FE
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.tonyw wrote: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 ?
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: SDK:C/make very slow with OS4.1FE
The GPL source code is included with every SDK so no need to bother me.xenic wrote:Maybe you could get that better idea by obtaining the make sources from ssolie.colinw wrote: 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.
ExecSG Team Lead