[plt-scheme] Memory, memory...

Matthew Flatt answers my doubts about the appetite of DrScheme:

>>It seems that the improvement
>>of the memory administration between 0.59 and 1.3 is gone now...
> 
> 
> The v200 series does indeed use roughly twice the memory of the v100
> series. That doubling holds at all levels: MzScheme, MrEd, and
> DrScheme.
> 
> It's not due to some new memory-management problem. It's that the
> software keeps growing with new features. Supporting an expressive
> macro system costs memory. Supporting reliable non-blocking output
> operations requires memory. Organizing code intro modules and building
> improved constructs in layers costs memory. A more sophisticated class
> system costs memory. Doubling the number of teaching languages costs
> memory. And so on.

Note that this doesn't answer my problem. The footprint of the *system*
is quite reasonable, I don't understand why it swells when it receives
Windows events!

> I think PLT Scheme is growing at a rate comparable to most any serious
> OS (e.g., Windows, Mac OS X, Linux). Although we put some effort into
> bloat control, it's not our research focus, so we don't expect to do
> better than other software.

That's alright, mind you. I repeat that I wanted to understand where this
memory allocation goes. This is *not* the result of macro system, teaching
languages, etc. [[All this, by the way, should be one day modularized and
loaded optionally, but I presume that this is not your major preoccupation
now]].


>>Python with wx, with Tkinter, with Numeric, PIL, etc.
>>doesn't go above 15M.
> 

> Perhaps one day those tools will evolve toward something approaching
> DrScheme's power. :)
> 
> Besides, it sounds like those things are more appropriate to compare to
> plain MrEd, which uses 1/2 to 1/3 of the space of DrScheme.

Matthew, you know that I love and I use DrScheme, but let's be fair. No
system with some pedagogic ambitions - as yours - can escape from
comparisons with something *alternative*, usable in similar contexts.
I do it all the time in order to delay my mental rigidity due to my
respectable age. The "power", as you say, is not just oodles of rarely
(sometimes) used code. [[BTW, it would not be appropriate to defend
the Python style/facilities on this list, but there is nothing to be
ashamed of, I happen to have recently taught both]].

Integrated, interfaced languages like Scheme, Smalltalk, Python (together
with wx / PyCrust, Idle or whatever; choose your interface/editor among
many...) tend to consume more and more memory because often they are
slaves of the underlying operating system imperfections. This may be the
case here. (E.g. the newer versions of Matlab consume 3 times more memory
than the version 5, without any real breakthrough in its 'power'; they
have Java-ised several internal administrative services, may Allah
forgive them this silly decision...). But some of them resist better
than others.

It is a pity that DrScheme is becoming a diplodocus as well. I repeat
that I use DrScheme, and I plan to continue this. You have done a
fabulous job, folks, you have my greatest respect and admiration. But
because of this, I feel entitled - *not* to criticize you, but to
wish to understand why a few things are not as ideal as I would like
to see.

Thank you.


Jerzy Karczmarczuk