[Prev][Next][Index][Thread]

Re: Improving performance and other stuff..



Dear Jon and Folks,

You can significantly improve the performance of Executor by  
rebuiling the kernel mods, with FASTALINETRAPS enabled.  To do this,  
edit the file /LocalApps/Executor.app/ardimods/Makefile.  Find a line  
that says:

# ARDIOPTIONS=-DFASTALINETRAPS

and delete the leading "# " sharp and space, so the line reads

ARDIOPTIONS=-DFASTALINETRAPS

Then issue the command "make ardimods_reloc".  It should look  
something like this (note, you need to be root to do this):

iclone# make ardimods_reloc

cc -g -DKERNEL -DKERNEL_FEATURES -DMACH   -c ardimods_main.c
cc  -c ardimods.s
cc -g -DKERNEL -DKERNEL_FEATURES -DMACH   -c ardimodc.c
kl_ld -n ardimods -l LoadCommands -u UnloadCommands -i instance  -o  
ardimods_reloc ardimods_main.o ardimods.o ardimodc.o

iclone# 


Now that you have the faster mods loaded, you can install them either  
by rebooting or using the kl_util program:

iclone# kl_util -d ardimods

removing server ardimods
Server ardimods deallocating
Server ardimods unloading
Server ardimods re-Allocated
Server ardimods Deallocated

iclone# kl_util -a ardimods_reloc

Adding server with relocatable  
/LocalApps/Executor.app/ardimods/ardimods_reloc
Allocating server ardimods
Server ardimods linking  
/LocalApps/Executor.app/ardimods/ardimods_reloc against /mach
Server ardimods linking relocatable  
"/LocalApps/Executor.app/ardimods/ardimods_reloc"
Server ardimods Allocated
Server ardimods loading
regs.pc = 4029564
Server ardimods download complete
Server ardimods starting up
Server ardimods Loaded

iclone# 


Note, when you use the "-d" option you say "ardimods", but when you  
use the "-a" option you say "ardimods_reloc".  "-d" stands for  
delete, "-a" stands for add.

The fast ardimods will be the default with 1.2.1, so performance will  
be enhanced.  I'm not sure which programs you're running where you  
see Executor get slower the longer it runs; I've spent hours in Word  
5 editting our manual and not noticed such a thing (but it could be  
that I was in a daze when I wrote our manual; it's a mind-numbing  
task, but someone had to do it).

If you find that your entire machine has slowed down to a crawl after  
running Executor, it means that the cache has not been turned back on  
(Executor turns the cache off and on very rapidly in order to get  
programs like Word 4 to run on an 040 even when they don't on an 040  
Mac).  THIS IS A BUG.  PLEASE REPORT THE EXACT CIRCUMSTANCES TO US  
(sending e-mail to bugs@ardi.com is the preferred method).  Executor  
is supposed to turn the cache back on, even if a program dies  
inexplicably.  If it is failing to do this, then it's a bug that we  
need to fix (we haven't seen it over here).

If you find your machine running slowly, you should be able to use  
the "cacheon" program to bring it back up to speed.  You can run  
cacheon either by typing it to the shell prompt in Terminal, or  
double clicking on it (it will be installed in the same directory  
that you installed Executor, presumably /LocalApps).

The new version of HFS_XFer that will be shipped with Executor 1.2.1  
will copy much faster (hooray!) and has a few bug fixed, but will not  
be able to do anything with files copied via NeXTSTEP 3.0.  As far as  
I know, NeXTSTEP 3.0 does not make the file type and file creator  
available to either end-users or programmers.  This is a major  
problem and NeXT knows about it, but unfortunately, even though it  
was brought to some peoples attention at NeXT last January, the right  
people didn't learn about it until it was too late.  I can't be  
totally sure that this is the case for official NeXTSTEP 3.0, but it  
was true for NeXTSTEP 3.0 PR1 and PR2.

	--Cliff