| Newsgroups |
gmane.comp.embedded.carlsbad-cubes |
| Message-ID |
<[email protected]> |
I'd say for what it is used for swixml is probably
just fine with jdom. I personally prefer pull parser
for size and speed and memory resources. But then
again I am a performance nut who will sacrafice some
things for speed.
That said, I don't see how the xml pull parsing is
harder to read than jdom? I find it easier. It is
simple string comparisons. Yes, a bunch of if
("..".equals())) else if () else if() isn't always
pretty, but it is fairly easy to read and easy at a
glance to know what specific node(s) you are working
with. So I would have to disagree that pull parser is
harder to read in code, and at the same time it is
much smaller, quite a bit faster and uses a lot less
memory resource at runtime. With all great things
comes sacrifice, and that would mean no dtd/schema
validator without an add-on to the pull parser.
--- [email protected] wrote:
> I'm writing Java apps (server side, client-side,
> JSPs etc) processing
> XML for a little mote than 4 years now.
> JDOM and Jaxen (XPATH) have been proven to be useful
> and effective!
>
> Yes, I have used SAX and "pure" DOM and considered
> pull. I have also
> used Piccolo and NANO where size and speed ready
> mattered.
> Since I do work on embedded systems as well, I
> understand the
> requirement for size and speed well and I have done
> optimizations that
> made code maintainability more difficult - but I
> always had a good
> reason.
> At this point, I'm not so sure that we should
> sacrifice readability and
> understandability of the Swixml code to reduce the
> size and improve the
> speed.
>
> The jdom.jar is about 128 kb, which is huge
> considering the size of the
> swixml.jar. On the other hand most project using
> Swixml deploy over an
> Intranet - so deployment size really doesn't matter
> all that much.
> Unfortunately, only a few Swixml users tell us how
> they use it ...
>
> Everyone would certainly benefit form improvements
> in processing speed
> - but usually Swixml descriptors are not 13MB - well
> at least not those
> that I have written - and speed improvement would be
> less impressive
> than those mentioned below.
>
> Pull parsing really seems to be the way to go but
> there are other - at
> this point maybe more important - things that need
> to be done.
>
> Maybe I'm misjudging the download size / execution
> speed issue.
> Is there anyone who considered using Swixml but
> didn't because of the
> download size or parsing speed?
>
> Wolf Paulus
>
> C a r l s b a d C u b e s
> mailto:[email protected]
>
>
>
> On Jan 2, 2004, at 9:03 PM, [email protected]
> wrote:
>
> > I agree, an XML pull parser would be perfect for
> this application,
> > however
> > either SAX or XML pull parsing would be a great
> improvement.
> >
> > Don
> >
> > On Fri, 2 Jan 2004 [email protected] wrote:
> >
> >> Frankly, I think you really should look at using
> xml
> >> pull parsing. For the type of xml parsing you do,
> xml
> >> pull would be super easy to implement, is quite a
> bit
> >> faster than SAX and is a mere 9K library that you
> can
> >> legally integrate directly into your swixml.jar
> file.
> >> I use it for my plugin engine and it is amazing
> how
> >> easy and fast it is. The only sax parser close in
> >> speed is picollo and I am not even sure where it
> >> stands now. xml pull is super easy:
> >>
> >> InputStream is = new
> FileInputStream("somefile.xml");
> >> XmlPullParser parser = new MXParser();
> >> parser.setInput(is);
> >>
> >> parser.next(); // move to first node
> >>
> >> int event;
> >>
> >> while ((event = parser.nextTag()) !=
> >> XmlPullParser.END_TAG)
> >> {
> >> if ("menu".equalsIgnoreCase(parser.getName()))
> >> {
> >> // do something
> >> }
> >> else if
> >> ("button".equalsIgnoreCase(parser.getName()))
> >> {
> >> // do something
> >> }
> >> else ...
> >> {
> >> }
> >> else
> >> {
> >> skipSubTree();
> >> }
> >> }
> >>
> >> That's about it. Sure, the more nested nodes the
> more
> >> while() loops you need, but the beauty is that if
> a
> >> node is not there, it skips over the rest of the
> >> nodes, and you control the parser, telling it
> when to
> >> get the next node for you. Further more, you can
> >> "break out" of parsing at any point, resulting in
> even
> >> faster parsing becuase you don't have to process
> every
> >> event like you do with Sax.
> >>
> >> The only caveat, which I think is null and void
> for
> >> swixml, is that it doesn't support DTD/xml schema
> out
> >> of the box, but you can add a sax validator to
> it.
> >> Frankly, for swixml, I would worry more about
> speed
> >> and size, and the xpp3 or kxml parsers will do
> exactly
> >> that for you!
> >>
> >> As a comparison, JDOM used 82MB of memory to
> >> load/parse a 13MB xml file. When I switched to
> xmlpull
> >> it took less than 3MB because I only parsed the
> nodes
> >> into objects as I needed them. The parsing speed
> >> improved 37x over the JDOM parsing/object
> creation
> >> speed. In my app, when selecting an xml file that
> >> would enforce parsing it, it went from 10+
> seconds per
> >> file to less than 1/2 second and almost
> instaneous
> >> showing of data on the screen. Yeah, I give up
> DTD/xml
> >> schema, but for size/speed and memory resources,
> it is
> >> WELL not having a validator, not to mentiond the
> extra
> >> time that would require as well.
> >>
> >> I can help put xmlpull in place if ya'll want.
> >>
> >> --- [email protected] wrote:
> >>> I looked at Jelly too, as they have several
> projects
> >>> that are similiar to
> >>> this one and have, from what I understand, a
> strong
> >>> XML framework for
> >>> processing markup. However, all that framework
> >>> takes processing,
> >>> third-party jars, and resources. What I like
> about
> >>> swix is how simple and
> >>> small it is. Yes, you can't use it to easily to
> >>> create other objects, but
> >>> by focusing on simply creating Swing (and
> perhaps
> >>> other GUI frameworks)
> >>> elements, you get speed, simplicity, and low
> >>> resource usage.
> >>>
> >>> That said, I think a move to SAX would be
> perfect
> >>> for swixml. Not only
> >>> does that remove the JDOM jar requirement, but
> SAX
> >>> is tons faster and
> >>> uses way less resources. To implement SAX in
> >>> swixml, I would probably try
> >>> to avoid creating an XML event pipeline if I
> could
> >>> help it. Yes, they are
> >>> very powerful and flexible (in fact, I'm using
> them
> >>> in several other
> >>> projects), but I think this project doesn't need
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003