[DayLateDon]

Hello ...

I've written a small program that, on one tester's iMac, takes up to 12 dock-bounces to launch. My comparably-outfitted iMac launches the app in about 4 dock-bounces. (Go figure.)

Specific bouncemarks aside, what are strategies for getting a program to launch as quickly as possible?


Thanks and regards ...

[tie]

The only one I know of is to split your nib files for different windows up. You should only load a nib file when it's needed, and this will save time at startup.

[Lolo from Paris]

I've seen those strange things on my iMac DV !

After using Techtools Pro (or Norton Utilies), you will see that apps launch faster...

The problem comes from the hard drive which is certainly not well optimized ! Maybe from RAM too...

[starfleetX]

Lolo is correct about drive optimization. Fragmentation can slow everything down A LOT.

Also, have you and your tester done your update_prebinding lately? This can signifigantly speed up application launching. If you need an explanation, search the forums: there are plenty of threads. Anyway, to update, open your terminal and enter:

sudo update_prebinding -root /

Give your password (assuming you're an admin for your machine) if you're asked for it. Now, this update should take several minutes and you really shouldn't interrupt the process, but you'll probably be delightfully surprised with the speed increase you get afterwords.

I hope this helps.

[ 06-03-2001: Message edited by: starfleetX ]

[Gregory]

If all we can do is optimize, we are in deep fry. MicroMat warns not to optimize using anything less than Drive 10 - TTPro 3 isn't up to it.

My drives are 0.1% fragmented, and never run a program to optimize since NU SD6 fried one. One drive is UFS and other is hfs+ - I actually think UFS is better for now. I don't trust fsck on hfs+.

Tests done on using optimizing programs on unix don't show real improvements, backup/initialize/restore is the only real reliable method used.

Norton SpeedDisk did such a job on one disk I had to RMA it back. Froze during optimize routine. Not a first either. (NUM 6.0)

I don't notice much difference running on an old 22GXP ATA/66 and a 10k SCSI -even though benchmarks suggest the ATA drive is 1/4 - 1/3 what the SCSI is capable of.

[DayLateDon]

Hello ...

My tester had done the pre-binding optimization before. But perhaps not after receiving my program. I'll ask him. (It would seem to be a(nother) strike against X's user-friendliness if that has to be done after every application install.)

The version of my app that my tester has had only one small window, so one nib. I've since added a couple of small alert sheets, which shouldn't have a significant effect on my bouncemark. (I haven't worked with multiple nibs yet: wouldn't they complicate connection assignments?)

I do run a number of set-up processes in an "awakeFromNib" method. But isn't "awakeFromNib" invoked after the bouncing ends? If not, then I could defer some of those processes to post-bounce processing (since they don't have any visual impact), but how do I inform my app that the bouncing has stopped?


Thanks for the advice.


By the way: Am I right that "nib" stands for "Next[Step] Interface Builder"? (I suppose it could be a reference to pen nib, but it takes a bit of a stretch to make that connection.) I don't recall running across a passage in the documentation that spells that out, and I've been wondering about it for almost a year now.