Hyperion Entertainment Message Boards

I finally got around to testing it on my FE partition on my X-1000.
It's clean except for all my prefs and S: files that I copied across from my working partition. I also copied the betatesters' version of RadeonHD.

Whereas my project takes 1m 30s under the betasystem, it took 1m 28s under FE.

The betasystem partition is FFS\07, the FE partition is SFS\02.

So, no problem here.

Raziel wrote:It would ne nice to know what exactly make has to do with Python then

Nothing whatsoever.

broadblues wrote:

Raziel wrote:It would ne nice to know what exactly make has to do with Python then

Nothing whatsoever.

That's true. Linking the problem to Python was a mistake on my part. To much boot partition swiching ended up leading me to a false conclusion. Sorry.

Linking the problem to Python was a mistake on my part. To much boot partition swiching ended up leading me to a false conclusion. Sorry.

I read all of the posts. What is the "take home" from all of this?

ggw wrote:I read all of the posts. What is the "take home" from all of this?

The "take home" is that some of us (programmers) have noticed a slowdown in compiling large sources after switching from OS4.1Update6 to OS4.1FE. Some people have confirmed the slowdown but others can't. For unknown reasons the slowdown is only apparent when you boot from an SFS partition with OS4.1FE. Compiling seems to work at the same speed as with OS4.1u6 when you boot from an FFS partition. There is more discussion of this in the "SDK:C/make very slow with OS4.1FE" topic in the SDK Support forum. Unless you are compiling huge sources and have noticed a dramatic slowdown, there is really nothing to be concerned about as far as I can tell.

Well I just have to add that I have also noticed that make seems unusually slow, even for smaller project, although projects that call make (not the same makefile) recursively one step. With the debug/verbose option I can see that make is doing A LOT of stuff, trying hundreds of default targets and stuff, but has that changed?

Also, I have noticed a general slowdown of disk (or DOS?) access. The disk light does not stay on longer than usual (i.e. it blinks just as short as on upd6). This is when Odyssey is accessing its cache. I normally has it switched off since it takes too much time. The net is faster than waiting for Odyssey to manage its cache, and the URL history doesn't work anyway.

I have a theory if this has to do with kernel memory management, because sometimes, I get audio and mouse pointer stuttering for no apparent reason. No task with high priority is running (although tasks are running). A humble guess is that exec is rearranging memory caches and takes waay too long to do so (over 250ms). Ideas?

@deniil

Netsurf complains about slow disk cache and suggests I turn it off.

System: Sam440ep-Flex, 1 GB RAM with SSD running 4.1 FE.

Deniil wrote:Well I just have to add that I have also noticed that make seems unusually slow, even for smaller project, although projects that call make (not the same makefile) recursively one step. With the debug/verbose option I can see that make is doing A LOT of stuff, trying hundreds of default targets and stuff, but has that changed?

My first solution to the "make" speed problem on OS4.1FE was to recompile an old version of make, which was faster but had other problems. Then I discovered that booting from an FFS partition caused the "make" command to operate faster (same as speed under OS4.1u6). More recently I discovered that if I boot from my SFS2 partition , then move the FFS partition "C" directory to the top of the system path list; I get fast compile speeds again. I use the command: path Workbench:C add head where WorkBench is the volume name of my FFS partition. You can confirm the speed difference by booting from an SFS partition and doing something like this: There is a significant speed difference but I can explain why adding the FFS "C:" directory to the top of the system path list makes such a difference in compile times. I should add that I have ENVARC:AppDir disabled because of command name conflicts between some commands I've added to my SDK and commands in my C: directory. I don't know if that has any effect on compile (make) speeds.

Also, I have noticed a general slowdown of disk (or DOS?) access. The disk light does not stay on longer than usual (i.e. it blinks just as short as on upd6). This is when Odyssey is accessing its cache. I normally has it switched off since it takes too much time. The net is faster than waiting for Odyssey to manage its cache, and the URL history doesn't work anyway.

I have a theory if this has to do with kernel memory management, because sometimes, I get audio and mouse pointer stuttering for no apparent reason. No task with high priority is running (although tasks are running). A humble guess is that exec is rearranging memory caches and takes waay too long to do so (over 250ms). Ideas?

I do get the impression of a general slowdown at times but can't reproduce it when booting from my SFS partition. Such problems were extremely noticable when I was booting from my FFS partition (to get faster compiles). When I reported some of these problems in the topic "General AmigaOS-Another system freeze", the response was that FFS is outdated and shouldn't be used. Any slowdown I get when booting from an SFS partition is so subtle that I can really what's going on or why it's happening.