[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