[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Eclipse: the new Emacs? (and the XML story)


eclipse emacs
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?

Mark

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>
>


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.