Hi Andy, hi Gunther,
Did you hear sth. about the performance of MarkLogic
My understanding is that on ML the presence typing blocks some tail-recursion optimizations leading to stack overflow for large texts.
Yes, this is how I got it, too. However, I was just wondering what’s the runtime for MarkLogic for the version without return types.
I found out it seems to be generally difficult to infer the static type of recursive functions as the one we discussed. However, I found another way to speed up the parser code:
The problem was that the positional access to sequences ($p:TRANSITION[$i0 ...]) was slow if it was not possible to statically assess that $i0 will be numeric. I have now added another implementation of the filter expression for filters with simple, deterministic predicates, which checks the predicate result type at runtime.
If the return type is omitted from p:map2(), the query is now appr. 15% slower, but this might still be ok. I would still love to see the types readded; but after all, this is not my code ;) A new snapshot is available [1].
Stack overflow is also an issue for my use of REx with BaseX, I would like to be able to parse sources like the FunctX library without having to set a large Java stack size. [1] (My report that the issue was fixed was incorrect). I would like to investigate if BaseX is using tail-recursion optimizations here and/or where/why this overflow happens - but it all looks very complicated :-).
If you find out more, please let us know!
Christian