Mmhh...ok. I will try to find it that way. I am actually trying to send you the prof:time(prof:mem)) of the main algorithm, to compare the main perf algorithm between the two betas. My first penny guess is that it could come from Leo's work, since INLINE and TAILCALL impacted the result. Could you be kind enough to point me out his January check-in ? Having a look to his check-in, if we are lucky, could help me isolate the problem.
2014-01-31 Christian Grün christian.gruen@gmail.com
If you got time, it may already be helpful if you provide us with your code base. You could also try to run BaseX with less memory assigned (e.g. 128m) and send us the stack trace, which will be triggered via the debug flag (-d) as soon as RAM is exhausted, or you could run BaseX with Java profiling arguments (e.g. -Xrunhprof:cpu=sample,depth=15) and provide us with the output. I can't promise anything, though.
On Thu, Jan 30, 2014 at 9:39 PM, jean-marc Mercier < jeanmarc.mercier@gmail.com> wrote:
Christian,
The point is that I don't know how to provide a self-contained query.
The only strategy I could propose, to provide a self-contained query isolating the memory management problem, is really too time-consuming : I can imagine a binary-chop search, comparing the memory management of the two BaseX beta versions, over a very complex algorithm, to isolate the problem. This is probably a week work, I can't spend such a time.
Do you have a better strategy to find the problem ?
2014-01-30 Christian Grün christian.gruen@gmail.com
A first clue: I set INLINELIMIT = 0 TAILCALL = -1, and the process ended,
even if it is taking now some 3/4 minutes and nearly 5,5 Go memory footprint.
Thanks. Could you provide us with a self-contained query? Christian