Lists Home |
Date Index |
I have not tried xmlbuddy, but all of the xml editors I have tried,
including oXygen ( and the Win32 ones XMLSpy, XMLNotepad, etc. ) exhibit
this behavior. Using RAM at 10 to 12 times the size of the document on
disk. I have always assumed it was because the were using DOM's
internally, and that the
DOM implementations were memory hogs. Any one have any wisdom to share here?
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?
> Everyone's idea of 'ready for prime time' will vary, but I assure you
> that people edit 400K XML documents all the time with XMLBuddy without
> ill effects. (The memory usage for relatively small documents like
> this, BTW, depends as much on the complexity and nature of the DTD or
> schema behind the document.)
> Bob Foster
> David Megginson wrote:
>> After flirting with it for a year or so, I've been giving Eclipse
>> another try for the past few days and have become convinced that it
>> will end up being the new Emacs: like Emacs, Eclipse is open source
>> and consists of a basic platform that provides a set of standard user
>> interfaces and services that are useful for many things other than
>> software development. Eclipse already has a collection of
>> third-party plugins (both open source and commercial) to rival Emacs'
>> collection of modes, and I'm sure that if it doesn't do e-mail yet,
>> it will soon.
>> I'm not ready to switch over to Eclipse for everything, but I am
>> trying it with a couple of Java and C++ projects (its CVS integration
>> is as good as Emacs'). While doing so, it occurred to me that if I
>> end up doing a lot of development in Eclipse, I'll probably end up
>> writing my XML documents in Eclipse as well, the same way that I've
>> been writing SGML and XML documents in Emacs for the past 15 years.
>> So I downloaded and installed two different XML editing plugins, both
>> derived from standalone editors:
>> 1. oXygen (commercial with free trial)
>> 2. XMLBuddy (free download for the basic version, closed source)
>> Both provide some useful features, such as integration with the
>> Eclipse outline view, syntax highlighting, validation, automatic
>> formatting, and (in oXygen's case) built-in well-formedness
>> checking. Neither provides an attributes dialog, as far as I could
>> find (just autocompletion for attribute names), and both lack basic
>> features from Emacs/PSGML like element splitting.
>> Unfortunately, neither editor is anywhere near ready for prime time.
>> I tried loading a 410K XML document into each of them (a bit over 100
>> pages printed), with the following results:
>> 1. oXygen works at first, but eventually causes a memory-exhaustion
>> error after a bit of editing.
>> 2. XMLBuddy becomes slower and slower, until it takes a few seconds
>> for each keystroke to register.
>> So, really, these tools are suitable only for writing short XML
>> configuration files or faqs, not books or manuals. I'm guessing that
>> the problem is an object explosion: the programs probably use Java
>> objects for everything, instead of optimizing internal storage with
>> arrays and building objects only on demand (it's the same kind of
>> problem that shows up with naively-written Java-based DOM libraries).
>> There is a third Eclipse XML editor plugin, X-Men, that is Open
>> Source. I didn't install it yet because it has some prerequisites
>> that I need to figure out, but since it's Open Source, when the time
>> does come to start writing XML documents in Eclipse, I'll be able to
>> go into the source code and fix any bottlenecks myself.
>> I'd love to hear other people's experiences with Eclipse and XML.
>> All the best,
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>