Re: Balloon 2.0 - Slow!

[amorton@ee.mu.OZ.AU (Anthony Morton)]

Diz writes:
>As others have noted, the main speed advantage of
>Balloon is that when you use it you don't have to
>quit your current application and run GS-ShrinkIt.
>But, beyond that, the main reason for the speed
>difference is that Ballon is an NDA and it has to
>live INSIDE an application.  So, it might not be able
>to grab all the memory needed to load a file
>completely into memory (like GS-ShrinkIt does), so,
>it plays it safe, which can sometimes mean playing it
>slow.

Sorry, but to me the argument as you've stated it makes little sense.  NDAs
only live 'inside' applications from the point of view of event handling
and tool set use; in all other respects they exist as independent entities.
In any case, _all_ chunks of code residing in the system, including NDAs,
CDAs, applications, GS/OS, init files and tool sets, are on an equal
footing as far as the Memory Manager is concerned.  If an NDA wants to
grab all available memory, there's nothing to stop it from doing so, apart
from the usual guidelines against memory-hogging which are adhered to by
all good DAs and applications alike.  It is this inherent flexibility in
the IIgs Memory Manager which IMHO makes it still the best of all PC MMs.
(Of all the operating systems I've had experience with, including GS/OS,
DOS/Windoze, MacOS and Unix, only Unix has superior memory management in
my opinion.)

The issue here is not whether an NDA is restricted in its memory use on
account of it being an NDA (it isn't), but whether the totality of objects
running in the system (including the current application, other DAs, and
GS/OS) are sufficiently economical in their collective memory use for the
NDA to run effectively.  Generally speaking, one memory-hogging item in the
system will cause all others to perform poorly, and it's a bit unfair to
blame the NDA for the peccadilloes of an unrelated application or system
extension.  If you were to run ShrinkItGS in conjunction with a memory-
hogging NDA you'd get just the same performance problem.  (Naturally, the
severity of such problems has everything to do with your RAM capacity.)

Perhaps this form of the argument is what you intended, in which case I
apologise for being pedantic.  But hopefully this contribution of mine will
help people to understand the issues.  It's not that NDAs are inherently
slower than applications; it's more a question of 'synergy' - a traditional
feature of UNIX applications and a feature being increasingly demanded of
today's software.

Just my 2 cents worth....

Tony Morton (amorton@ee.mu.oz.au)
Electrical Engineering Masters student & diehard IIGS lover
University of Melbourne, Australia