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

Re: full-blown application in MACL?



I am also *very* concerned about application size, speed and gc.  I
think people using MCL either play with it as a toy, do research or
develop commercial applications (admittedly "complex applications").  I
therefore really think that these issues are quite important for the
last 2 categories and *very* important for the last category.
 
My guess is the following:
 
- application size is *somewhat* important, but not that much for me.
As I said, the application developed is rather complex, and I agree that
it would anyway have to run on a big mac (not the one from
macdonalds...), ie with a large disk and some RAM.  The clients of such
applications (which are expensive because complex) shouldn't mind too
much the extra-ram cost.  Moreover, hardware is changing so fast that it
is less and less a problem.
 
- application speed is also *somewhat* important.  But here again, the
same remarks apply.  Also, there is usually lots of room for optimizing
the code (I know this is not the case for loading big images & so on).
But there, what would be *very* useful is some kind of performance
meter, like Symbolics'.  I know there is one PD performance meter in CL
utilities, managed by Mark ??? (sorry, Mark, I forgot your last name),
but I haven't tried it.
 
- But for me, the most negative point is the intrusive GC.  This is not
user-friendly at all...  And this is not usual on a MAC application.
Moreover, according to Murphy, it always happens when you don't want it
to...  on the other hand (and Apple wrote a lot about this recently),
lots of time are spent idle by the computer, waiting for the user.  This
is an idea I totally agree upon.  For me, performance is often a
psychological view in the sense that the user doesn't want to wait for
certain things, but leaves the computer idle.  
 
Therefore, reorganizing computation for it to take place when the user
isn't waiting for some result is a very intereting thing to do.  Of
course, this is not always possible, but GC is the typical computation
the user doesn't want results from (apart from working on with more
memory).  Therefore, if the programmer could manage the GC's work to
nicely fit its application underuse of the computing power, it seems to
me that the overall "psychological performance" could be much better.
 
I don't say this would be easy to do, but it could be interesting.  For
this to be possible, we need apple to implement incremental and
program-controllable GC... Not an easy task, but a big plus for MCL.
 
 
Vincent Keunen
NRB