[basex-talk] Same query, huge difference in performance

Hi, I have two XQueries that do exactly the same thing, i.e. create a list of waters in the Facts database and display where these waters flow into, if any. But Query 1 executes 10 times faster than Query 2 (in the GUI). The only difference is in the selection of the query context. Query 1 as

[basex-talk] Question about the mailing-list

A bit off-topic but this weekend I ran into a strange issue with this mailinglist. I tried to send a message from the same e-mail address I am using now (p...@swennenhuis.nl) but it bounced back every time I tried. I get the feeling that the subscription is not merely e-mail based but also IP ad

Re: [basex-talk] Same query, huge difference in performance

Hi Paul, Op 4 aug. 2014, om 09:27 heeft Paul Swennenhuis < p...@swennenhuis.nl > het volgende geschreven: Listings: Query1 (: list waters and where they stream to (if any):) for $source in //(sea|river|lake)let $toId := $source/to/@water let $to := (//sea|//river|//lake)[@id=$

Re: [basex-talk] Copy between databases

Hi Marco, > what is the best way to copy/move collections of resources from one db to > another? Here is one way to do it: db:open('source', 'a') ! db:add('target', ., db:path(.)) Cheers, Christian

Re: [basex-talk] UPDINDEX and ever growing index size

Hi Christian, > I’m glad to tell you that I have now implemented the projected optimizations Thank you for providing the snapshot. I’ve downloaded it and begun running some tests. Unfortunately I’m immediately finding some odd behaviour. I’m using the script I provided in my original issue rep

Re: [basex-talk] Same query, huge difference in performance

Hi Huub, Thank you for your reply. I tried your suggestions, but it does not make any difference. I changed Query 1 to this: (: list waters and where they stream to (if any):) for $source in //(sea|river|lake) let $toId := $source/to/@water let $to := //*[@id=$toId][1] let $name := if (empty($t

Re: [basex-talk] Copy between databases

Dear Christian, Is data serialized/deserialized in your example, Or is it working directly on the internal data format ? Best regards, Fabrice Etanchaud Questel/Orbit -Message d'origine- De : basex-talk-boun...@mailman.uni-konstanz.de [mailto:basex-talk-boun...@mailman.uni-konstanz.de]

Re: [basex-talk] UPDINDEX and ever growing index size

James, thanks for testing. We have a bunch of test cases that succeeded for the rewritten index handling, but as it seems, we definitely need some more. I'm pretty sure it's a single bug that causes all the error messages (because the code is in itself pretty straightforward), so I would be glad i

Re: [basex-talk] Copy between databases

> Is data serialized/deserialized in your example, > Or is it working directly on the internal data format ? No data will be serialized in this example, but it may happen that, due to the semantics of the pending update, you may encounter OutOfMemory issues when copying very large documents. Chri

Re: [basex-talk] Question about the mailing-list

> A bit off-topic but this weekend I ran into a strange issue with this > mailinglist. > I tried to send a message from the same e-mail address I am using now > (p...@swennenhuis.nl) but it bounced back every time I tried. > I get the feeling that the subscription is not merely e-mail based but als

Re: [basex-talk] Same query, huge difference in performance

Dear Paul, Is it a big collection ? Could the difference be in opening the collection ? Did you try to run the slow request for example in the GUI, with the collection already opened ? Best regards, Fabrice De : basex-talk-boun...@mailman.uni-konstanz.de [mailto:basex-talk-boun...@mailman.uni-

Re: [basex-talk] Same query, huge difference in performance

Hi Paul, > //(sea|river|lake) Due to the (somewhat peculiar) semantics of XPath, this path is identical to... /descendant-or-self::node()/ (child::sea | child::river | child::lake) ...and it creates a massive amount of intermediate results. You could try to rewrite it to... /descendant

Re: [basex-talk] Same query, huge difference in performance

Hi Fabrice, Thanks for your contribution. The collection is the Facts database (factbook.xml) found in the distribution of BaseX. It's the same collection as used in Query 2. And yes, I did try to run the slow query in the GUI. In fact, that is the only place where I ran it, with the Facts dat

Re: [basex-talk] Same query, huge difference in performance

Hi Christian, Sorry, also doesn't improve performance. I even tried to copy the optimized line for the selection, as found in the Query Info pane: (: list waters and where they stream to (if any):) for $source in ((db:open-pre("facts",0)/descendant::*:sea union db:open-pre("facts",0)/descen

Re: [basex-talk] Same query, huge difference in performance

Hi Paul, thanks for your feedback. Are you working with 7.9? If it's not too much of a hassle for you, I would be interested to hear if you get better performance with the latest 8.0 snapshot? Christian [1] http://files.basex.org/releases/latest/ On Mon, Aug 4, 2014 at 11:57 AM, Paul Swennenh

Re: [basex-talk] Same query, huge difference in performance

Hi Christian, I will try that. But first: I can confirm my suspicion. The offending line ( let $to := //*[@id=$toId][1] ) takes about 20 msecs per hit , and since there are 249 hits, that means 249 * 20 = 4980 msecs in total, almost 5 seconds! On a side note: I discovered that BaseX's query

Re: [basex-talk] Same query, huge difference in performance

Hi Christian, Just tried the query in BaseX 8. Sorry, no improvement in performance. Paul Hi Paul, thanks for your feedback. Are you working with 7.9? If it's not too much of a hassle for you, I would be interested to hear if you get better performance with the latest 8.0 snapshot? Christian

Re: [basex-talk] Same query, huge difference in performance

Hi Paul, thanks for trying 8.0. I have just uploaded yet another snapshot that optimizes descendant-or-self axes and union & list expressions; e.g.: //(sea, river) -> (/descendant::sea | /descendant::river ) There are various other query optimizations that will be available in 8.0. But as y

Re: [basex-talk] Same query, huge difference in performance

Hi Christian, Thanks again for your reply. I'm learning a lot by discussing these kind of problems. I tested your variant. It does indeed perform a lot better. My Query 2 still beats it though, so I'll stick to that one for now. Paul Hi Paul, thanks for trying 8.0. I have just uploaded yet an

Re: [basex-talk] UPDINDEX and ever growing index size

Hi James, I've found a little example for the bug (see attached). Sorry for the inconvenience; I'm working on a fix. Christian On Mon, Aug 4, 2014 at 11:30 AM, Christian Grün wrote: > James, > > thanks for testing. We have a bunch of test cases that succeeded for > the rewritten index handl

Re: [basex-talk] UPDINDEX and ever growing index size

The bug was hidden well [1], but it should be fixed now. Could you check out the latest snapshot? Christian [1] https://github.com/BaseXdb/basex/commit/429585ce26fca98d124d78fb88216ad7317c52fa On Mon, Aug 4, 2014 at 2:41 PM, Christian Grün wrote: > Hi James, > > I've found a little example fo

Re: [basex-talk] UPDINDEX and ever growing index size

A last one for today: I have just uploaded another snapshot which should speed up index updates. Looking forward to your feedback, Christian On Mon, Aug 4, 2014 at 4:01 PM, Christian Grün wrote: > The bug was hidden well [1], but it should be fixed now. Could you > check out the latest snapsho