| Newsgroups |
gmane.comp.embedded.carlsbad-cubes |
| Message-ID |
<[email protected]> |
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
>