OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Eclipse: the new Emacs? (and the XML story)

[ Lists Home | Date Index | Thread 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
> http://xmlbuddy.com/
> 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,
>> David
> -----------------------------------------------------------------
> 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>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS