[jdom-interest] New benchmark

[KUMAR,PANKAJ (HP-Cupertino,ex1)]

Hi Alex,

Thanks for looking at xpb4j !!

As you may have seen in an earlier mail of mine, I was using an indexed
traversal to traverse through children of a node and that apparently is a
particularly slow operation. Ref:
https://sourceforge.net/tracker/index.php?func=detail&aid=576754&group_id=37
214&atid=419698

This, ofcourse, does not mean that the issue you are referring to would not
improve performance even more. I would be curious to run xpb4j with
JDOM-b9!!

/Pankaj.

-----Original Message-----
From: Alex Rosen [mailto:arosen at silverstream.com]
Sent: Tuesday, July 02, 2002 12:21 PM
To: 'Jason Hunter'; 'JDOM Interest'
Cc: pankaj_kumar at users.sourceforge.net
Subject: RE: [jdom-interest] New benchmark


> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of Jason Hunter
> Sent: Tuesday, July 02, 2002 2:50 PM
> To: JDOM Interest
> Subject: [jdom-interest] New benchmark
>
>
> http://xmlhack.com/read.php?item=1706
>
> Interesting reading.  JDOM's looking pretty good (and that's
> particularly impressive since b8 had the StringBuffer
> performance bug).
>
> But look at the last chart.  There's clearly some bug there we need to
> track down!

Great article!

I think that last problem is exactly the beta8 StringBuffer issue. When
parsing large files, the particular way we used StringBuffer meant that the
GC had a really hard time reclaiming the char arrays that it threw off, even
though there weren't reachable. I remember looking at it in Optimize-It, and
all of these char arrays were still being held on to, by references that
were called... I forget, some name that implied that they were ready for
freeing, but hadn't actually been freed. We fixed this a few days after beta
8, and it caused the parse time on Dennis' much_ado.xml file (198K) to be
reduced by an order of magnitude, if I remember correctly.

Alex