Syntax to use profiling functions on updating functions
Hi, I can't seem to use the profiling functions on updating functions. I was wondering if it's a known limit or if I just need to use a different syntax in this context. For example in an updating function that returns 2 updates, I have something like this declare updating function
translation:import-and-process-returned-translations($package-number as xs:string) { .... some code .... return ( translation:save-space-issues($package-name, $space-issues) => prof:time('Translate save space issues: '), translation:save-source-mismatches($package-name, $source-mismatches) => prof:time('Translate save source mismatches: '), translation:save-zhtw-brackets-issues($menu-id, $package-name) => prof:time('Translate check zhtw brackets, not saved?: ') ) };
This works with the prof:time, but if I try to profile, I get: [XUST0001] Expressions must all be updating or return an empty sequence. Thanks! P.S. By the way, I'm very excited about the improvements I am able to implement now that I can use the performance functions in this module. I'm one version late to say this, but awesome addition! -- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com
Hi France, I can't seem to use the profiling functions on updating functions. I was
wondering if it's a known limit
The XQuery spec requires function arguments to be non-updating; maybe that answers your question? What exactly do you want to measure? The time for preparing your update (i.e. the construction of the pending update list), or the execution time of the actual update? This works with the prof:time, but if I try to profile, I get:
I’m not sure if I understand this phrase. How do you try to profile? P.S. By the way, I'm very excited about the improvements I am able to
implement now that I can use the performance functions in this module. I'm one version late to say this, but awesome addition!
Good to hear. Do you refer to prof:track? Best, Christian
The idea was to test at the higher level all the larger updating functions to know which one to tackle on 1st, sometimes I can't really test inside the function either. For example, if the inside if the function is: for $in in db:open('x')//* let $blah := ... return replace value of node $in/@class with 'blah' So I guess that's the limit to what can be tested without creating an external call and testing from the outside layer (en call fthe function in js rom httprequest and time from js.) I mostly use prof:time... It's the most useful to us, at least for now. On Tue, Dec 31, 2019 at 8:51 PM Christian Grün <christian.gruen@gmail.com> wrote:
Hi France,
I can't seem to use the profiling functions on updating functions. I was
wondering if it's a known limit
The XQuery spec requires function arguments to be non-updating; maybe that answers your question?
What exactly do you want to measure? The time for preparing your update (i.e. the construction of the pending update list), or the execution time of the actual update?
This works with the prof:time, but if I try to profile, I get:
I’m not sure if I understand this phrase. How do you try to profile?
P.S. By the way, I'm very excited about the improvements I am able to
implement now that I can use the performance functions in this module. I'm one version late to say this, but awesome addition!
Good to hear. Do you refer to prof:track?
Best, Christian
-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com
participants (2)
-
Christian Grün -
France Baril