Subject: RE: [xsl] Latest XSLTMark benchmark From: "Kevin Jones" <kjouk@xxxxxxxxxxx> Date: Tue, 3 Apr 2001 19:24:46 +0100 |
>> Perhaps an alternative is to measure performance on increasingly >> large input documents to show the memory scalability of a >> processor. > >That was my thinking, but I am not sure why you say that kb/kb >figure wouldn't work in that case. I guess you might get greater >than 100% efficiency, but that is somewhat true -- at the cost of >additional cpu resources. That's the difficulty, if we are going to start seeing more advanced DOM implementations around. For example, what happens if you base an XSLT processor directly on a database. You could just say the figures don't make any sense but more likely it depends a lot on the configuration of the DOM as to what speed/memory trade off you get. Maybe this is just asking too much of one benchmark to cover all these cases. > >(BTW, are we ever going to get to include Napa in our benchmark >result releases? Your site implies you have a driver...) > Hope so. There is a driver that I have been using myself but I haven't wanted to promote Napa too much recently while I get it to a 1.0 release and stabilise the implementation model. Kev. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Latest XSLTMark benchmark, Eugene Kuznetsov | Thread | Re: [xsl] Latest XSLTMark benchmark, Uche Ogbuji |
Re: [xsl] XSLT editor, Scott Sanders | Date | Re: [xsl] sorting and merging, Francis Norton |
Month |