[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: eXelon performance
> > OK, so it seems obvious that bringing the DOM in mem and searching using
> > Xalan is not a very good solution.
> This is not what we are actual doing with ozone/XML. We directly
> run XPath on
> the persistent DOM. Each DOM Element is a database object.
OK. I miss understood your message. When you said "Xalan needs approx. 1.8s
x 30 = 54s (for all 30 files) to process the query on in-memory DOM!" I
thought this was regarding Xalan processing in ozone, but now that I read it
again... I know I'm mistaken.
> Directly accessing the DOM from Java via something like
> document.getChild(1).getChild(2) is possible rigth now.
It would probably be better to use this approach than XPath query when
possible then. Any idea on how much faster it would be? Just a wild guess of
course.
> But this
> is not the
> same an a XPath query.
True.
> IMO XML data binding is intended to map business logic that is
> already coded
> in Java to XML. If you will, DOM is the most general data binding
> because it
> does not depend on any kind of business logic, you can use it if
> you want to
> handle any kind of XML data. So making a new XML -> object
> mapping makes no
> sense, we already have DOM. However, making such a new Java object
> representation regarding a special query lang solution would ofc
> ourse make
> sense.
I was more or less thinking of trying to optimize the process by having
specialized classes, but then it defeats the purpose of XML. Not really the
best approach, but in my case, I would have to come up with some alternative
approach... 5 minutes for every Xpath query on 5 megs of data is not
practicle... I'm sure you agree. I'm not shooting down ozone or anything
here. Just saying some sort of alternative approach would be needed. Doing
ODMG type queries on the DOM, might work better once it is implemented. Of
course, I'm just talking out of my ***.
> But because we are unable to make a new query solution (or even
> implement XPath), we have to use software that is there already.
> And so we are
> supporting DOM because Xalan and all other packages use it. So
> the only way
> for us to improve performance of ozone/XML is to optimize our DOM
> to better meet
> the needs of ozone and XPath. (and meanwhile wait for a better Xalan)
> softwarebuero m&b (SMB)
Right, this is understandable.
-david