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