wayne@helix.nih.gov (Wayne Rasband) (09/04/90)
After upgrading my cx to an fx, I noticed a curious phenomenon with the public domain image processing program(NIH Image) I'm developing: it was taking much longer to open a large number of windows. On the cx, Image can open 50 256x256 MRI Scans in 24 seconds, but on the fx, it takes 135 seconds. After putting in some debugging code, I discovered that the NewPtr call used to allocate the 64K PixMap for each window was taking about 1/4 second on the cx, and an incredible five seconds(!!!) on the fx. Does someone know why NewPtr is up to 20 times slower on the fx? Wayne Rasband (wayne@helix.nih.gov)
jwhitnell@cup.portal.com (Jerry D Whitnell) (09/07/90)
Wayne Rasband (wayne@helix.nih.gov) writes... |After putting in some debugging code, I discovered that the |NewPtr call used to allocate the 64K PixMap for each window was taking |about 1/4 second on the cx, and an incredible five seconds(!!!) on the fx. |Does someone know why NewPtr is up to 20 times slower on the fx? | |Wayne Rasband (wayne@helix.nih.gov) Remember, NewPtr allocates memory at the bottom of the heap, so it has to move everything above it up to make room. This means that if there is more stuff on the heap, it will take longer. Another possiblity may have to do with the FX being 32-bit clean. A technique I prefer for allocating large chunks of fixed memory is to call NewHandle, followed by a MoveHHi and an HLock. This puts the memory at the top of the heap where it is out of the way. You may find this faster. Jerry Whitnell SuperMac Technology
dvorak@vaxa.cc.uwa.oz.au (09/08/90)
In article <478@nih-csl.nih.gov>, wayne@helix.nih.gov (Wayne Rasband) writes: > NewPtr call used to allocate the 64K PixMap for each window was taking > about 1/4 second on the cx, and an incredible five seconds(!!!) on the fx. Sounds impossible to me.Is the MMU turned on in the fx, remapping things? I doubt it would intoduce that sort of a delay though...Have you accidently turned on the CLEAR option? Is there some sort of heap-checking proc in effect? At 40Mhz, nothing should take 5 seconds... Darko Volaric. -- ------------------------------------------------------------------------------ Phone: +61 9 330 2876 D V O R A K C O M P U T E R dvorak@vaxa.cc.uwa.oz.au ------------------------------------------------------------------------------
mneerach@a.inf.ethz.ch (Matthias Ulrich Neeracher) (09/10/90)
In article <33606@cup.portal.com> jwhitnell@cup.portal.com (Jerry D Whitnell) writes: > A technique I prefer for allocating large >chunks of fixed memory is to call NewHandle, followed by a MoveHHi and an >HLock. This puts the memory at the top of the heap where it is out of the >way. You may find this faster. ... or you may not. I have never done actual timing comparisons, but I often had the impression that MoveHHi can be quite slow, since it seems to compact more or less the whole heap. >Jerry Whitnell >SuperMac Technology Matthias ----- Matthias Neeracher mneerach@inf.ethz.ch "I wouldn't recommend sex, drugs or insanity for everyone, but they've always worked for me" -- Hunter S. Thompson
wayne@helix.nih.gov (Wayne Rasband) (09/10/90)
>At 40Mhz, nothing should take 5 seconds...
Believe it or not, on the fx, when there are several thousand objects on
the heap, NewPtr can take up to 5 seconds to allocate a large block. Apple
DTS says NewPtr is slower on the fx and ci because of the need to make the
ROMs on these machine "32-bit clean". I could understand NewPtr getting 10
or 20 percent slower, but I can't imagine why it got 50 times slower.
Wayne Rasband (wayne@helix.nih.gov)