ken@gvax.cs.cornell.edu (Ken Birman) (12/12/89)
Jerry Jackson at SAIC privately raised the question of "why ISIS runnable code is so large", and he and I ended up having a look. It turns out that the system is incorrectly linking in a lot of junk. I'll fix this in ISIS V2.0; meanwhile, you can patch something together if you need a quick fix. Basically, the deal is this (figures on SUN OS 4.0.x) 1) SUNLWP is 65k extra code; since it slows ISIS down as well, I will probably disable it by default in ISIS V2.0 2) The guard evaluation code, which apparently isn't being used by anyone, totals about 80k more. I think I will discontinue support for this code in ISIS V2.0 and beyond; the META sensors are more powerful and can solve all the same problems. 3) The package for logging/automated recovery/news totals about 175k. This is needed if you use PG_LOGGED or news or rmgr, but otherwise can be dispensed with; right now, it always gets linked in (all of it) 4) The spooler is getting linked in even if you don't use it. In fact, you only need a little stub and the "send" side can be linked only if used. All told, this should get the runtime overhead down to about 120k. However, if you build ISIS V2.0 with the bypass option enabled, expect a good size extra hit -- perhaps 250k or so, counting code but also the buffering this mechanism needs. Since BYPASS is a compile time option, you can eventually get fancy and have a BYPASS and non-BYPASS library if necessary. Some other factors: gcc produces faster and smaller code; we see about a 10-20% improvement when using gcc depending on what we do. I probably won't make this the default in our makefiles, because many people don't have gcc installed, but it really is a hot compiler. Also, you are quite safe using gcc with optimization. To get anywhere close to this, you need to use "cc" with optimization level 3 (-O3). However, I still don't trust this optimization facility on the SUN4 and HP Spectrum systems... Also, gcc -g or cc -g seems to emit much larger object files and modestly larger runtime images than if -g is not specified (-g lets dbx and gdb run on your program). I'll ship ISIS V2.0 with -g disabled, but this makes the ISIS clib something of a black hole when debugging. Jerry had a few other good ideas, but I'll give him a chance to post them on his own... Ken PS: I just learned that a company has been shipping an ISIS based product (and making money off it) for some time. Unfortunately, they don't want to post anything, out of concern that this will tip off the competition. I would be interested in hearing of any other success stories. Don't worry, we won't divulge names and will protect the innocent, etc...