enk@noddy (Edan Kabatchnik) (07/22/89)
Net,
It is pretty clear that by adding INITs to your system you pay a time
penalty while booting your machine. My questions to you are:
1) Does the bottleneck arise from the actual loading of the INITs or
the seek time in between INITs? (Of course, this may vary from
machine to machine depending on processor, hard disk, etc.)
2) If the bottleneck is the seek time, then is it possible to cut down
boot time by combining all the INITs into one (preferably contiguous)
file?
I have sucessfully combined two INITs into one file; however, it is
often the case that two INITs share identical resource numbers, which
prevents them from being combined (at least to my knowledge).
If anyone has done this or knows anything about it, I would appreciate
your expertise.
--------------------------------------------------------------------------------
DOMAIN: enk@sj.ate.slb.com, enk@wheaties.ai.mit.edu
INTERNET: sj.ate.slb.com!enk@slcs.slb.com, enk%sj@slcs.slb.com
UUCP: {amdahl,decwrl,uunet}!sjsca4!enk
PHONE: (408) 437-5178
USMAIL: Edan Kabatchnik
c/o Schlumberger Technologies
1601 Technology Drive
San Jose, CA 95110louis@asterix.drev.dnd.ca (Louis Demers) (07/23/89)
In article <1179@snjsn1.SJ.ATE.SLB.COM>, enk@noddy (Edan Kabatchnik) writes: > > 1) Does the bottleneck arise from the actual loading of the INITs or > the seek time in between INITs? Yesterday, I reformatted my drive and restored my system. All inits were restored alphabetically (the order they happen to be executed) and next time I rebooted , the speed at which those little icons at the bottom were flashing was surprising. That would support your idea. ****************************************************************************** * Louis Demers * Defence Research Establishment Valcartier * * office = (418) 844-4424 * Electro-Optics Division * * lab = (418) 844-4265 * P.O. Box 8800 * * bed = (418) 839-9266 * 2459 PIE XI Blvd. * * louis@asterix.drev.dnd.ca * Courcelette, Quebec * * demers@ncs.dnd.ca * CANADA, G0A 1R0 * ******************************************************************************
ts@cup.portal.com (Tim W Smith) (07/25/89)
I would guess that most INITs would not be bothered by having their resource ID changed. So if you want to try stuffing a bunch of them into the same file, and you get resource number conflicts, just renumber the conflicting ones. Don't, however, renumber other resources in the INIT files, unless you know what you are doing. Tim Smith
mikem@uhccux.uhcc.hawaii.edu (Mike Morton) (07/27/89)
In article <20731@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >I would guess that most INITs would not be bothered by >having their resource ID changed. What about folks who get their own code by: GetResource ('INIT', 0); so they can then do a DetachResource on themselves? -- Mike Morton // P.O. Box 11378, Honolulu, HI 96828, (808) 676-6966 HST Internet: mikem@uhccux.uhcc.hawaii.edu (anagrams): Mr. Machine Tool; Ethical Mormon; Chosen Immortal; etc.
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (07/27/89)
In article <4430@uhccux.uhcc.hawaii.edu> mikem@uhccux.UUCP (Mike Morton) writes: :In article <20731@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: ::I would guess that most INITs would not be bothered by ::having their resource ID changed. : :What about folks who get their own code by: : GetResource ('INIT', 0); :so they can then do a DetachResource on themselves? They should know better. :) ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
philf@lindy.Stanford.EDU (Phil Fernandez) (07/31/89)
In article <1179@snjsn1.SJ.ATE.SLB.COM> enk@sj.ate.slb.com (Edan Kabatchnik) writes: > 1) Does the bottleneck arise from the actual loading of the INITs or > the seek time in between INITs? (Of course, this may vary from > machine to machine depending on processor, hard disk, etc.) My theory is disk performance. I have a IIx and a IIcx, with identical configurations except for the hard disk performance specs. The IIcx has an 18ms disk, the IIx a 25ms disk. I use quite a few INITs, and I've noticed an extreme difference in boot-up speek between the machines -- the IIcx boots in just slightly more than 1/2 the time. I figure that difference is the time it takes to chase down and load the INIT code. pmf +-----------------------------+----------------------------------------------+ | Phil Fernandez | philf@metaphor.com | | | ...!decwrl!metaphor!philf | | Metaphor Computer Systems |"Does the mind rule the body, or does the body| | Mountain View, CA | rule the mind? I dunno..." - Morrissey | +-----------------------------+----------------------------------------------+
dplatt@coherent.com (Dave Platt) (08/01/89)
In article <1179@snjsn1.SJ.ATE.SLB.COM> enk@sj.ate.slb.com (Edan Kabatchnik) writes: > 1) Does the bottleneck arise from the actual loading of the INITs or > the seek time in between INITs? (Of course, this may vary from > machine to machine depending on processor, hard disk, etc.) Disk performance has a great deal to do with it. In fact, performance can vary greatly even on a single model of disk, depending on the efficiency of the disk driver. The following anecdote illustrates this point. I have a Mac II and a Micah AT-100 drive... the Micah uses a Rodime 100-meg (5000S series) mechanism (access time ~~ 28 msec typical). I used the Micah-supplied driver for 6-8 months... performance was good, and the system booted quite nicely. After System 6.0 came out, I discovered that the Micah driver was vulnerable to a bug that Apple had introduced in System 6.0; the drive could not be formatted, or verified via Disk First Aid. I switched over to another driver-package that the folks at Micah sent me... I believe it was a member of the driver-family written and marketed by Software Architects. It was compatible with System 6.0, and could partition my 100-meg disk into several subvolumes (something that the Micah driver for the Mac II could not do). But WOW, was it slow! Booting the machine and running my collection of INITs took almost twice as long as under the Micah driver. The drive seemed to spend lots of time with its "busy" light on, but wasn't getting nearly as much work done as before. The whole system had a more sluggish feel to it. A couple of months later, I received a copy of the latest version of Rodime's disk-driver software from Rodime's tech-support group... compatible with 6.0, and capable of partitioning a Rodime disk. I backed up my disk, reformatted using the Rodime utility, and restored the files. Lo and behold, the disk's performance was back up in the same ballpark as before... the INIT-icons popped up one after another, with no agonizing pause between them. The system's overall "feel" was no longer painfully sluggish. I _think_ that the Micah driver may have been a hair faster than the Rodime driver... but both the Micah and Rodime drivers were far and away more efficient than the Software Architects driver. I suspect that the SA driver may have been making lots of small (single-block) transfer requests, while the Micah and Rodime drivers were able to make larger requests (possibly with some sort of in-memory cache in the driver itself). -- Dave Platt FIDONET: Dave Platt on 1:204/444 VOICE: (415) 493-8805 UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
han@Apple.COM (Byron Han) (08/01/89)
In article <4430@uhccux.uhcc.hawaii.edu> mikem@uhccux.UUCP (Mike Morton) writes: >What about folks who get their own code by: > GetResource ('INIT', 0); >so they can then do a DetachResource on themselves? > To get at your code, do a RecoverHandle(@entryPoint) and then HLock the resulting handle. +-----------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-----------------------------------------------------------------------------+ Byron Han, Communications Scapegoat At Apple, we change the world everyday. Apple Computer, Inc. ----------------------------------------- 20525 Mariani Ave, MS27Y Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han ------------------------------------ GENIE:BYRONHAN CompuServe:72167,1664 ATTnet: 408-974-6450 Applelink:HAN1 HAN1@applelink.apple.COM -------------------------------------------------------------------------------
werner@molokai.sw.mcc.com (Werner Uhrig) (08/01/89)
Dave Platt reports how changing drivers changed boot time significantly. One aspect that I have not seen mentioned is the fact that having INITs located close together (on the same cylinder) will cause a tremendous speed difference in booting in contrast to the situation where the INITs are all over the disk, especially if you have a hard disk (and software) with a RAM-cache ... I know, I know, the next question you want answered is how to force all INITs onto the same cylinder. I'll leave that to someone else .... Cheers, ---Werner -- --------------------------> please send REPLIES to <------------------------ INTERNET: werner@rascal.ics.utexas.edu UUCP: ...<well-connected-site>!rascal.ics.utexas.edu!werner ALTERNATIVE: werner@astro.as.utexas.edu OR werner@utastro.UUCP
dwb@sticks.apple.com (David W. Berry) (08/12/89)
In article <4430@uhccux.uhcc.hawaii.edu> mikem@uhccux.UUCP (Mike Morton) writes: >In article <20731@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >>I would guess that most INITs would not be bothered by >>having their resource ID changed. > >What about folks who get their own code by: > GetResource ('INIT', 0); >so they can then do a DetachResource on themselves? The preferred method is: _start: bra.s Entry dc.l 'INIT' dc.w 0 dc.w 0 Entry: lea _start,a0 _RecoverHandle _DetachResource It's portable and doesn't depend on you knowing what id you were installed as. Opinions: MINE, ALL MINE! (greedy evil chuckle) David W. Berry (A/UX Toolbox Engineer) dwb@apple.com 973-5168@408.MaBell AppleLink: berry1
blm@6sigma.UUCP (Brian Matthews) (08/13/89)
In article <3516@internal.Apple.COM> dwb@sticks.apple.com (David W. Berry) writes: |In article <4430@uhccux.uhcc.hawaii.edu> mikem@uhccux.UUCP (Mike Morton) writes: |>In article <20731@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: |>>I would guess that most INITs would not be bothered by |>>having their resource ID changed. |>What about folks who get their own code by: |> GetResource ('INIT', 0); |The preferred method is: [standard method for an INIT to get a handle to itself] |It's portable and doesn't depend on you knowing what id you were |installed as. And of course we know that every Mac programmer uses only the most portable method of doing things :-). I agree that anyone who writes an INIT and gets a handle to the INIT any other way should be hit over the head with all of Inside Mac. However, that doesn't mean that everyone does it that way, so if you're renumbering INITs, you definitely need to worry about INITs doing GetResource ('INIT', 0) -- Brian L. Matthews blm@6sigma.UUCP Six Sigma CASE, Inc. +1 206 854 6578 PO Box 40316, Bellevue, WA 98004
ts@cup.portal.com (Tim W Smith) (08/18/89)
If you really want to stuff a bunch of INITs into one file, and are worried about resource ID conflicts among the INITs or resources they use, you could write an INIT to resolve these. It would work like this: The Init Packer application would let you choose a bunch of files containing INITs. It stuffs them all into a file. If there are any resource ID conflicts when stuffing the file, it renumbers the conflicting resources. It places an INIT 0 in the file, and it places a resource that tells what resources it had to renumber, and how it renumbered them. You place the file in your System folder and reboot. INIT 0 patches GetResource ( and whatever else uses resource IDs ). The patch to GetResource watches for attempts to get resources that were renumbered and substitutes the correct number. This could be a fun program/INIT to write. Tim Smith