| Newsgroups |
gmane.comp.embedded.carlsbad-cubes |
| Message-ID |
<[email protected]> |
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
>>> their overhead.
>>> Furthermore, by not creating an object tree modeling
>>> the XML, either of
>>> JDOM objects or Tag objects, we are using much less
>>> resources and doing
>>> less processing.
>>>
>>> Would a move to SAX result in more parsing code?
>>> Absolutely, and in fact,
>>> the code would probably get a little harder to
>>> follow, however, I think
>>> the benefits far outwiegh the costs. Look at how
>>> far thinlet has gotten
>>> and it's all in one class! :) (not that I'm
>>> suggesting that of course)
>>>
>>> By moving to SAX, swixml would be stream-based,
>>> generating objects as it
>>> parses, rather than waiting till a xml object tree
>>> is created first.
>>> There are a couple of features of swixml, xincludes
>>> and attribute
>>> copying, that we'd have to work around, but I think
>>> it is still
>>> doable.
>>>
>>> Don
>>>
>>> On Mon, 29 Dec 2003, Brian P Michael wrote:
>>>
>>>> Don,
>>>>
>>>> I wanted to get back with you regarding your
>>> questions about SAX.
>>>>
>>>> I decided to pause my efforts and take an in-depth
>>> look at Jelly.
>>>>
>>>> To describe SAX parsing, SAX uses a parse for each
>>> of the following:
>>>> Begin Document
>>>> Begin Tag
>>>> End Tag
>>>> Begin CDATA
>>>> End CDATA
>>>> End Document
>>>>
>>>> and some others, but that will do for this
>>> explanation.
>>>>
>>>> Jelly uses SAX to parse it's documents. I
>>> describe this parse as a
>>>> two-pass parse.
>>>>
>>>> The first pass, Jelly uses SAX to create an event
>>> pipeline, parsing the
>>>> document as it goes. During this pass, Jelly
>>> builds a tree of all TAGs
>>>> using their "Tag" class.
>>>>
>>>> This class tree, stores all the pertinent
>>> information necessary to
>>>> instantiate java classes, including information
>>> about
>>>> parent/child relationships and element
>>> hierarchies.
>>>>
>>>> At this stage, the XML Document has been read,
>>> parsed and processed.
>>>>
>>>> The second phase of the two-pass parse, then reads
>>> the TAG Tree and
>>>> instantiates the java classes associated with tag.
>>>>
>>>>
>>>> So to parse the following (Taken from the
>>> Accelerator.xml sample):
>>>>
>>>> <frame name="mainframe" size="640,480" title="S W
>>> I X M L"
>>>>
>>>
>> plaf="com.sun.java.swing.plaf.windows.WindowsLookAndFeel">
>>>> <menubar name="menubar">
>>>> <menu name="filemenu" text="File">
>>>> <menuitem name="mi_new" text="New"
>>> icon="samples/icons/new.gif"
>>>> mnemonic="VK_N" accelerator="control N"
>>> Action="newAction"/>
>>>> <menuitem name="mi_open" text="Open"
>>> icon="samples/icons/open.gif"
>>>> mnemonic="VK_O" Accelerator="control O"
>>> ActionCommand="open"/>
>>>> <menuitem name="mi_save" text="Save"
>>> icon="samples/icons/save.gif"
>>>> mnemonic="VK_S" ActionCommand="save"/>
>>>> <separator/>
>>>> <menuitem name="mi_exit" text="Exit"
>>> icon="samples/icons/exit.gif"
>>>> mnemonic="VK_X" Accelerator="control X"
>>> ActionCommand="exit"/>
>>>> </menu>
>>>> <menu text="Help">
>>>> <menuitem name="mi_about" text="About"
>>> enabled="true"
>>>> icon="samples/icons/info.gif" Accelerator="alt A"
>>> Action="aboutAction"
>>>> />
>>>> </menu>
>>>> </menubar>
>>>>
>>>> 1) Jelly uses SAX to parse each tag
>>>> a) SAX parses the begin document
>>>> b) SAX sees the beginning of a new tag, <frame>
>>>> It then Parses the <frame> tag, instantiating a
>>> new Tag object for
>>>> the frame tag.
>>>>
>>>> c) SAX then sees the beginning of the new tag,
>>> parses the <menubar> tag
>>>> It Parses the <menubar> tag, instantiating a new
>>> Tag object for the
>>>> <menubar> tag
>>>>
>>>> d) SAX then sees the beginning of the <menu> tag
>>>> etc, etc
>>>> e) SAX then sees the end tag of <menuitem>,.....
>>>> etc.
>>>> etc
>>>> etc
>>>> e) SAX parses the end document
>>>>
>>>> 2) Parse continues using the begin tag, end tag
>>> scenario.
>>>>
>>>> 3) Jelly then runs through the tree of newly
>>> created objects and
>>>> "compiles" it.
>>>> As it runs through the compile, it then parses
>>> the tree, building and
>>>> instantiating
>>>> the swing objects as it runs the compile.
>>>>
>>>> For standard Java Beans, with standard getter
>>> and setters, a
>>>> "DynaBean" tag was created in phase 1.
>>>> The real object is then instantiated.
>>>>
>>>> For all other objects, a "DoTag" method on the
>>> parser of that object
>>>> is called.
>>>>
>>>> This "DoTag" is then called and runs the
>>> appropriate code to build the
>>>> object, add children, etc.
>>>>
>>>> In Jelly, the parsing of the document goes very
>>> quickly. Much faster
>>>> than our current SwiXML.
>>>> During the second phase of parsing/compiling,
>>> Jelly executes basically
>>>> everything Swixml executes during Swixml's first
>>> and only pass.
>>>> So, the second pass takes time.
>>>>
>>>> I haven't actually taken statistics on the timing,
>>> but pass 1 goes
>>>> really quick. Pass 2 is where most of the
>>>> work is performed.
>>>>
>>>> Now considering, Jelly is now parsing an in-memory
>>> Tag Tree, similar to
>>>> parsing the XML Document, I have to
>>>> believe that the time it takes would be similar to
>>> the single pass of
>>>> Swixml.
>>>
>> === 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
>>
>
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>
>
>