Hello, just something I noticed.
I was trying to check the variables of one of my functions, but it only returned an empty string. Reading [1] http://docs.basex.org/wiki/Profiling_Module#prof:variables gave me the impression that disabling inlining (locally or globally) would return these values. But it doesn't work for me in version 9.1.1 or latest snapshot. I tested it on 8.4.4 and it works, so either it is a regression or a changed behaviour. I usually open an issue on Github directly but I think you now prefer it in the mail list first.
Regards,
George
Hi George,
I usually open an issue on Github directly but I think you now prefer it in the mail list first.
Exactly (too many issues were created in the past that were hidden questions, or were based on misunderstandings).
I was trying to check the variables of one of my functions, but it only returned an empty string. Reading [1] gave me the impression that disabling inlining (locally or globally) would return these values. But it doesn't work for me in version 9.1.1 or latest snapshot.
Do you have a self-contained example that shows the behavior?
Thanks in advance, Christian
Do you have a self-contained example that shows the behavior?
Thanks in advance, Christian
Sorry for not providing one, I thought it was easy to reproduce. Trying the example from the wiki:|for $x in 1 to 2 return prof:variables()|
|Will return empty strings in 9.1.1 while it returns valid result (1,2) in version 8.4.4 - So I guess it's not an issue with inlining but with prof:variables() itself. |
|George. |
Sorry for not providing one, I thought it was easy to reproduce. Trying the example from the wiki: for $x in 1 to 2 return prof:variables()
Thanks, I can reproduce this now. The reason why the log output has changed is that some new optimizations were added in BaseX. As the variable $x will never be referenced in the subsequent expressions, the query is rewritten to:
for $x in util:replicate("", 2) return prof:variables()
The empty string is just a dummy here (internally, it’s a static object that requires no repeated instantiations of objects that will never be referenced).
I have updated the example in the documentation:
for $x in 1 to 2 return ($x, prof:variables())
Hope this helps, Christian
Do you have a self-contained example that shows the behavior?
Thanks in advance, Christian
Actually looking at the compilation information it looks like something more is going on there. \
This example returns the following compilation information and optimized query:
declare %basex:inline(0) function local:test() { for $x in 1 to 200 return 1 };
local:test()
Compiling: - pre-evaluate range expression to range sequence: (1 to 200) - pre-evaluate range sequence to singleton xs:string sequence: (1 to 200) -> util:replicate("", 200) - pre-evaluate util:replicate(items,count) to singleton xs:integer sequence: util:replicate(1, 200) - pre-evaluate FLWOR expression to singleton xs:integer sequence: for $x_0 in util:replicate("", 200) retu... -> util:replicate(1, 200) - inline local:test#0 Optimized Query: util:replicate(1, 200)
-----
But trying to return prof:variables() returns the following compilation information and optimized query:
for $x in 1 to 2 return prof:variables()
Compiling: - pre-evaluate range expression to range sequence: (1 to 2) - pre-evaluate range sequence to singleton xs:string sequence: (1 to 2) -> util:replicate("", 2) Optimized Query: for $x_0 in util:replicate("", 2) return prof:variables()
It looks like there is an issue both with prof:variables(), and maybe with inlining. Why is the compilation for the first example tries to inline the function even if I have defined it to 0? in BaseX 8.4.4 that doesn't happen.
Thanks again,
George
Oh yes, many things are happening here; I am always surprised by myself. Here is some background information:
• Up to now, the body of a function was always inlined if it is a static value, no matter which value is currently assigned as inline limit. • BaseX 9 pre-evaluates your function body to a value (a so-called "singleton sequence", to be exact; it is represented as “SingletonSeq” in the query plan). • As a result, the body was inlined with BaseX 9, whereas it was not in previous versions.
The decision to ignore the inline limit if the function body is a value has been taken 6 years ago, so I cannot recollect what was the reason behind that. I decided to change this optimization rules, though (in practice, hardly anyone will notice this, as it’s only observable if the function inlining limit is changed). The behavior of the latest snapshot may be easier to understand now [1].
Hope this helps Christian
On 1/14/19 5:08 PM, Christian Grün wrote:
Oh yes, many things are happening here; I am always surprised by myself. Here is some background information:
• Up to now, the body of a function was always inlined if it is a static value, no matter which value is currently assigned as inline limit. • BaseX 9 pre-evaluates your function body to a value (a so-called "singleton sequence", to be exact; it is represented as “SingletonSeq” in the query plan). • As a result, the body was inlined with BaseX 9, whereas it was not in previous versions.
The decision to ignore the inline limit if the function body is a value has been taken 6 years ago, so I cannot recollect what was the reason behind that. I decided to change this optimization rules, though (in practice, hardly anyone will notice this, as it’s only observable if the function inlining limit is changed). The behavior of the latest snapshot may be easier to understand now [1].
Hope this helps Christian
Thanks Christian, I will use this snapshot, always happy to help testing :)
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
George Sofianos