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

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

Sigh, it would have helped if I attached the bug number.  See
    http://bugs.eclipse.org/bugs/show_bug.cgi?id=36112

Jeff

"Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx> wrote in message
news:b6pe3s$d6n$1@xxxxxxxxxxxxxxxx
>
> "Kevin" <kduffey@xxxxxxxxxxxxx> wrote in message
> news:b6olbs$r6g$1@xxxxxxxxxxxxxxxx
> > 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.
> > 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.
>
> This sounds great. To try this out in the Eclipse context, could you
> prototype pull parsing the plugin structure?  Basically replace the class
> PluginParser in org.eclipse.core.runtime.  It is currently a SAX parser.
> The DTD is very simple and is spec'd in the runtime doc.  Once we have an
> idea of the speed/space improvement there we can recommend to plugin
writers
> how to us this technique for their parsing.
>
> I have created a bug report for this work.  You can attach a patch or
whole
> new parser when you feel its worth trying.
>
> Jeff
>
>