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

Re: Balisage Bard: On performance, persistence, and p

Subject: Re: Balisage Bard: On performance, persistence, and pointers to parents
From: "BR Chrisman brchrisman@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 31 Jul 2020 00:02:37 -0000
Re:  Balisage Bard: On performance
parent pointers: rather have them and not need them, than need them
and not have them... but either way, the optimizer better know my
'haves' from my 'needs' :)

On Thu, Jul 30, 2020 at 4:38 PM Damian Morris damian@xxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> This is fabulous, Michael :)
>
>
>
> On 31 Jul 2020, at 4:24 am, Michael Kay mike@xxxxxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> For those who weren't there, and those who were and can bear hearing it again, here's my contribution to the famous Balisage Bard session.
>
> It's an abridged version of my XML Prague 2018 paper, and describes work done during the development of the XSLT compiler now released as part of Saxon-JS 2.
>
> On performance, persistence, and pointers to parents
>
> We wrote a compiler for XSLT
> Like any compiler, its heart is a tree.
> In each of its phases it transforms this tree
> And the transforms are written in XSLT.
>
> If the input and output compare line by line,
> Then an XSL transform takes linear time.
> Though the changes you make may be local and small
> You still pay the price of transforming it all.
>
> The reason it's costly is easy to see:
> The non-changing content itself is a tree.
> Not only do nodes point to children, to boot,
> They also link up to the document root.
> When subtrees are used in a new destination,
> These pointers are switched to a brand new location.
> The larger the corpus, the longer it takes;
> Work needed just for consistency's sake.
>
> In a functional programming language like Scheme,
> You don't have this problem: it works like a dream.
> With immutable structures like binary trees,
> Making many small changes is fast as the breeze.
> It works much more quickly because it's arranged
> So you only touch branches whose content has changed.
>
> That's why JSON works so well:
> With JSON trees (I have to tell),
> Parent pointers are not needed:
> Copy speed is not impeded.
>
> But the pointers to parents are there for a purpose,
> It cannot be said that their presence is worthless.
> The freedom to navigate upwards and down
> Means the rules for transforming each fragment of prose
> Can depend on its context (whence it arose).
> So if xml:lang says your paragraph's Dutch,
> This may affect formats for numbers and such,
> But to know just what language applies at your focus,
> You need to go up to establish its locus.
>
> The point of this poem is perfectly plain,
> So let's wrap it up and repeat it again:
> Decisions you make when designing your data
> Determine the speed of all that comes later.
> While pointers to parents have justification,
> They stultify subsequent optimization.
>
> XSL-List info and archive
> EasyUnsubscribe (by email)

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.