Re: [Exist-open] query optimaization questions

[Pierrick B. <pie...@cu...>]

Hi,

Robert Koberg a =E9crit :

> A couple of questions on queries:

Better 2 threads then ;-)

> 1. In the logs,  looking at the debug output for Query diagnostics, I s=
ee
> code that is written like:
>=20
> <p class=3D"myclass">some text</p>
>=20
> being rewritten in a more pure form (don't know the correct terminology=
)=20
> like:
>=20
> element {"p"} {
>    attribute {class} {
>      myclass
>    }
>    text {
>      some text
>    }
> }
>=20
> Would it be better for compilation performance/speed to write the=20
> queries in this more 'pure' form? Does it matter?

First, if you want performance... don't log :-)

Then, this is due to the way eXist handles computed and constructed=20
elements.

Roughly, constructed elements are handled like computed ones.  This is=20
the job of the org.exist.xquery.ElementConstructor class. The result you=20
see is just what is returned by the toString() method, which is=20
generally used to degugging and... logging.

One may think about a way to have something more elegant there, perhaps=20
with a flag indicating that we have a constructed element...

> 2. Is it better to have one main query .xql that imports all necessary=20
> common modules and switch off flow there. Or is it better to have many=20
> smaller .xql's and have each of those import common modules on their=20
> own. For example:
>=20
> admin.xql imports:
>    -- list-users.xqm
>    -- list-groups.xqm
>=20
> versus:
>=20
> list-users.xql imports:
>    -- admin.xqm
> list-groups.xql imports:
>    -- admin.xqm
>=20
> In other words, does admin.xqm get compiled once and is reused when=20
> imported or does admin.xqm get reparsed/compiled for each time it is=20
> imported?

For sure, the bigger the better : you pay a price for compilation but=20
after that, your compiled query is cached. This is a good investments so =
:-)

I'm not sure however how a change in an imported module is handled ; of=20
course, this should trigger a recompilation. Not sure if it currently=20
does...

As always, a test case is welcome.

Cheers,

--=20
Pierrick Brihaye, informaticien
Service r=E9gional de l'Inventaire / DRAC Bretagne
mailto:pie...@cu... / t=E9l : +33 (0)2 99 29 67 78
Avez-vous lu http://usenet-fr.news.eu.org/fr-chartes/rfc1855.html ?