Tracking it down wasn't much help because the message
watcher threw me off thinking the problem was the TableManager
(sorry Jan)... Besides the fact that the message watcher is nearly
useless, it throws in all the RR's messages to confuse you and
doesn't tell you where the message came from... The more stacks
or windows (scritp editors for ex.) you open, the more messages you
get to confuse you...
Click the Suppress button in the Message Watcher and you have all sorts
of options for telling the Message Watcher what messages to ignore.
When a line appears, select it to see where it came from.
Anyway, my stack was really slow all the time and the problem was
untraceable... Then I noticed that a message suspendstack was
saving the stack at each suspendstack... Nothing wrong there
except that whenever I went to the revprops or revtools or revmenu
palette, my stack would get a suspendstack event!!!!!!!!!!
It seems to me that you would have a lot more cause to complain if
going to a different stack did NOT send a suspendStack message!
However, if your save stack routine is causing you problems, that may
be due to your saving method. If you are using the internal "revSave"
handler either in a script or by calling the Save menu item directly,
it throws up a dialog box telling you what has been saved. This box
stays open for 2 seconds but you can of course edit the script for that
if you want. If you use the simpler "save this stack", you will not get
the dialog and saving should be so fast as to be undetectable. The
disadvantage is that it does not compact the stack so if you have been
adding or deleting lots of objects, you should do a menu save every now
& then.
Since RR is ultra slow, ultra-cpu-hog, I couldn't be get more and
more irritated... On a 2.8 MHz P4 512MBs, this is a shame, and
a real bummer for productivity...
Why would a 10 K stack take 5 seconds to save and hog your CPU
at 55 % (or 99% hog on a 1.8MHz P4...)?
IS THAT NORMAL?
This is NOT normal behavior and I believe we are all affected!
No it is not normal and no we are not all affected. I think you are
blaming Rev for something that you have added as the default
installation of Rev is not "ultra slow" and is not an "ultra-cpu-hog".
Check what stacks you have in use and whether you have added an front
or back scripts. Something you are doing is causing this lack of
performance and leading to your frustration. I have numerous plugins
running constantly, both my own, Rev's and those contributed by others
and I have none of these problems.
Sarah
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution