[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: improving performance in creating ids

Subject: Re: improving performance in creating ids
From: "Pieter Lamers pieter.lamers@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 23 Apr 2019 14:28:32 -0000
Re:  improving performance in creating ids
Hi Martin,

Thanks for your quick reply. the node identity comparison helped quite a bit, although I am still around a minute for a full book of ids. I am not sure how xsl:number would help here, and what kind of performance win it would give over count(). I tried something with a nested transformation, but what should I feed it?

B B B <xsl:number select="*[last()]"/>
works (given a set of preceding nodes) but it is slightly slower than a count() in the xquery. Maybe I should be using xsl:number differently?


however, your suggestion of nesting transformations also opens the door to using generate-id() in the xquery realm, with a nested transformation, thereby sidestepping the problem that eXist returns something different for generate-id() from Saxon (also in reply toB Dave Pawson).

I will see where that gets me.

tx
Pieter


On 23/04/2019 14:19, Martin Honnen martin.honnen@xxxxxx wrote:
On 23.04.2019 14:07, Pieter Lamers pieter.lamers@xxxxxxxxxxxx wrote:
Hi All,

I need generated-ids on elements in a BITS file that have @rids, so I
can link back to them. I cannot use generate-id(), because I need it to
produce the same id in both the xquery (eXist) context and in the XSL
(saxon) contect.

I have created a function that will generate a human readable id based
on the id of the nearest ancestor/@id and then element-name + sequence
number. It produces the output that I like, but at the cost of a poor
performance (when run on a whole book) . now with the preceding/ancestor
juggling that I do there might be a better way than mine, so my question
is if there is a better way to tackle this problem.

My function:

declare function local:get-id-in-doc ( $target as element() ) as xs:string
{
B B let $current-element as xs:string := local-name($target)
B B let $ancestor-with-id as element()? := $target/ancestor::*[@id][1]
B B let $prefix as xs:string? := $ancestor-with-id/@id/string()


B B  let $count :=
B B B B  if($prefix) then
B B B B B B  (: case 1: there is an ancestor with an @id :)
B B B B B B  count($target/preceding::*[local-name() eq
$current-element][ancestor::* = $ancestor-with-id]) + 1

That general value comparison


B ancestor::* = $ancestor-with-id

looks odd, shouldn't that be

B ancestor::*[. is $ancestor-with-id]

? I would expect node identity comparison and not value comparison.

Whether that improves performance and then also on two different
implementations is something I can't tell without testing.



2. Is there an alternative way of generating ids (possibly having less
human-readable values) that would work in both the xquery and xslt realm?

It looks like a job for XSLT's xsl:number and I wonder whether your database xquery processor doesn't provide a way to simply run an XSLT transformation.


-- Pieter Lamers John Benjamins Publishing Company Postal Address: P.O. Box 36224, 1020 ME AMSTERDAM, The Netherlands Visiting Address: Klaprozenweg 75G, 1033 NN AMSTERDAM, The Netherlands Warehouse: Kelvinstraat 11-13, 1446 TK PURMEREND, The Netherlands tel: +31 20 630 4747 web: www.benjamins.com

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.