[news.eclipse.technology.equinox] Re: Work items posted

["Kevin" <kduffey@xxxxxxxxxxxxx>]

I can only give you my own time tables that I have seen in terms of how fast
XMLPullParsing is. I was using JDOM on a 11MB file. It ate up 80+MB in
memory and took over 20 seconds to load/parse on my PIII 800Mhz with 512MB
RAM. The same file took less than 2 seconds using either of the two current
xml pull parser implementations at the xmlpull.org site (xpp3 and mxparser).
It didn't come close to even 15MB or memory being used. These are ROUGH
times and memory consumption, I did not use pro caliber tools.

However, for things like parsing plugin xml files, writing config files out,
or parsing web service xml input/output, as far as I am concerned nothing
comes close to being as easy, fast and resource-free as xml pull parsing.
Yeah, it may look a little different in code, but the code is super beginner
easy to deal with, runs VERY fast, and you can validate inline, or add a
validation class via the xml pull API for validation. I think there is a
Xerces xmlpull tie-in as well, read the site (xmlpull.org) for more info. I
think if Eclipse wants to speed up the parsing of xml, switching to xmlpull
would be a huge improvement in this area. I am willing to bet that it will
increase the performance of all xml related tasks exponentially in eclipse.
Not sure though exactly where/how xml parsing is being used. It would no
doubt require a complete retrofit of the current parsing though.

I am rather surprised that xmlpull hasn't been getting more attention given
its small size (25K), extremely fast speed and less resource usage than a
SAX2 parser! Again, it may be a bit unconventional compared to dom/jdom/sax
parsing, but I find it much faster, easier and more maintanable.

And having used it for some time, I can offer my help in this area.


"Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx> wrote in message
news:b6k5np$9ku$1@xxxxxxxxxxxxxxxx
> Meta note:  Lets stick to plain text posts in the newsgroup.
>
> "Kevin" <supreme_java_guru_1@xxxxxxxxx> wrote in message
> news:b6j2lq$9ql$1@xxxxxxxxxxxxxxxx
>
> ....I think Eclipse, OSGi and other approaches (JEdit, IDEA, etc) all have
> some good things in them. But mostly, I wanted a very tiny engine that
could
> easily be embeded and used in any type of application, not just GUI. I
found
> with Eclipse at the time, it was built around SWT and the plugin.xml
format
> was heavily tied into the GUI to allow lazy activation of plugins when
menu
> items or buttons were clicked. I have adopted the lazy
>
> <jm>Some clarification... The Eclipse runtime is not GUI based or related.
> The plugin model is completely devoid of any GUI notions.  There are many
> applications of Eclipse which are entirely headless.
> </jm>
>
> The XML Pull Parser is not a 100% XML compliant parser in that it doesn't
do
> DTD or XML Schema validation, nor is it by any means the normal DOM or SAX
> type of code to parse the xml file. It is however faster than every parser
> out there, at least from the last tests done on it, it also uses less
memory
> than SAX2 parsing, and the code is extremely easy to figure out and work
> with. I would think the parsing of the plugin.xml files, and any other
.xml
>
> <jm>This is interesting.  Currently Eclipse uses Xerces for all its XML
> parsing.  The Eclipse requirements are very modest and Xerces is largely
> overkill (as well as being 1.2MB on disk).
> </jm>
>
> So, while I'd like to keep on using my own tiny little "kernel" of an
engine
> that provides the basics of eclipse and OSGi with the simplicity of a few
> lines of code to develop a plugin, I'd also like to possibly help out with
> the OSGi/Eclipse marriage (I assume that is what Equinox is about?) to see
a
> better overall architecture, that
>
> <jm>The goals of Equinox are mentioned on the web site.  An Eclipse/OSGi
> marriage is not a stated goal though it may well be an outcome.  The
> ultimate goals are centered around dynamic plugins, increased flexibility,
> service models, ...  We'll use/create whatever technology helps reach
those
> goals.
> </jm>
>
> Jeff
>
>