Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!sdd.hp.com!usc!apple!alan.aux.apple.com!abm
From: abm@alan.aux.apple.com (Alan Mimms)
Newsgroups: comp.unix.aux
Subject: Re: A/UX concerns
Message-ID: <12230@goofy.Apple.COM>
Date: 22 Feb 91 22:11:01 GMT
References: <8570@etsu.CMI.COM> <250@raysnec.UUCP> <1991Feb20.082410.20817@nada.kth.se> <12183@goofy.Apple.COM> <1991Feb21.175045.26404@nada.kth.se>
Sender: usenet@Apple.COM
Reply-To: abm@alan.aux.apple.com (Alan Mimms)
Organization: Apple Computer, Inc.
Lines: 56

In article <1991Feb21.175045.26404@nada.kth.se>, d88-jwa@dront.nada.kth.se (Jon W{tte) writes:
|> In article <12183@goofy.Apple.COM> abm@alan.aux.apple.com (Alan Mimms) writes:
|> >.Would you like to expound on what you found "doggy"?  I use an FX on
|> >System 6.0.5, System 7.0, and A/UX 2.0.1, and find them all to be
|> 
|> The 24bit environment under A/UX, compiling using THINK C, is slower
|> than on an SE/30 - _definately_ slower than on a "plain" IIfx.
|> (FYI: this was while compiling the TCL, lots of tiny files including
|> lots of headers, though the headers stay the same all the time)

This almost certainly due to the fact that you're access zillions of
teeny Mac files from a Unix filesystem.  If you use a real HFS file
system you'll win performance-wise.  As in any emulation, making one
kind of filesystem appear to be another, while maintaining complete
transparency of operation, takes some time -- especially when the
files are OPENED, which you do a lot when you access zillions of tiny
files with LSC.

|> >Perhaps you're trying to run A/UX on a tiny memory machine (4MB is not
|> >really the best light to view A/UX in)?
|> 
|> 8MB, and from what I see (and hear :-) there+s no paging nor (gosh)
|> swapping.

Yes, I do not believe that's the problem here now.

|> >I'm not trying to be combative -- I (we) would like to know what's wrong
|> >so we can fix it or help you to use it in a way that shows off A/UX's best
|> >qualities...
|> 
|> Oh, and this is using Berkley file systems on two quantum 80 megs -
|> fast search, not-so-fast transfer. But anyway, I don't think memory
|> is the problem here.
|> 
|> >Alan Mimms (alan@apple.com, ...!apple!alan)   | My opinions are generally
|> 
|> Maybe splitting the project file in two files would speed things up.
|> How slow is the "apple single" format ?

AppleSingle is just fine if the resource fork never changes size.
If you ARE changing the resource fork a lot (which you ARE on
LSC project files), you want to make it Apple Double.  Or move to an
HFS disk partition.

|> 								h+
|> "The IM-IV file manager chapter documents zillions of calls, all of which
|> seem to do almost the same thing and none of which seem to do what I want
|> them to do."  --  Juri Munkki in comp.sys.mac.programmer

-- 

Alan Mimms (alan@apple.com, ...!apple!alan)   | My opinions are generally
A/UX X group                                  | pretty worthless, but
Apple Computer                                | they *are* my own...
"Laugha whila you can, monkey boy..." -- John Whorfin in Buckaroo Banzai
"Never rub another man's rhubarb" -- The Joker in BatMan