| Newsgroups |
gmane.comp.embedded.carlsbad-cubes |
| Message-ID |
<[email protected]> |
I've used XMLPull and I've used SAX and I've used JDOM
yes XMLPull is easier to read than SAX, but the last time I checked
you needed 2 Jars to get XML pull working.. one the core classes and
one for the implementors of those core classes.
so, you've lost your download size advantage.
XMLPull is a wrapper around SAX, so now you've gone and added
processing overhead.
so, if your goal is a faster smaller app it makes no sense to use
XMLPull. SAX is annoying yes but if you're going to do the work to make
the app faster then it really doesn't make any sense to add a wrapper
around the fastest possibility. (This is assuming SAX really is the
fastest option)
now, if your goes is easy of use and maintainability, then I have to
agree with Wolf that JDOM is the way to go.
I should note that I have nothing against XMLPull, it just isn't the
right choice if you're truly after speed and size.
-Kate
On Jan 3, 2004, at 2:34 AM, [email protected] wrote:
> 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
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com