[
Lists Home |
Date Index |
Thread Index
]
Bob Foster wrote:
> It may be problem you're running into with your 401K document is that
> Eclipse itself, not just the editors that run in it, is something of a
> memory hog. If you're running Eclipse in its default max memory, around
> 100MB, any significant work you do will get Eclipse near the limit,
> putting you into a constant garbage-collection mode, which slows things
> down considerably.
>
> I personally don't run Eclipse except with the following added to the
> command line:
>
> -vmargs -Xmx256m
>
> I know this comes as a shock to people coming from emacs or otherwise
> unused to running in an all-Java environment not particularly tuned for
> low memory usage, but there it is. The question is, do you want to spend
> your time optimizing away the need for a <$100 memory chip?
Thanks for the hint -- that seems to speed things up a little, but it still
lags far behind my typing speed: I think it manages about 25 wpm.
Obviously, that won't be a problem for the hunt-and-peck types, but it's an
annoyance for even a modest touch-typing speed of 60-70 wpm. I have no idea
whether that's a problem with Eclipse, the XMLBuddy plugin, or both (I
haven't tried XMLBuddy standalone). I turned off the options to validate in
the background and keep the outline up to date, but it made no difference.
As for optimizing memory, one consideration is markets other than PCs. If
you need 256M to edit a DocBook 400K document (admittedly, not all of that
is used by the editor itself), then the handheld and small-device market is
effectively closed off. I agree that premature optimisation is bad, but
with DOM-like in-memory data structures, a modest amount of tuning can bring
enormous memory savings (basically, use arrays internally wherever possible
and generate objects only on request).
All the best,
David
|
