2

I have an algorithm, which works recursively relatively deep, such that a maximum stack size exceeded exception eventually occurs (without being an endless recursion!).

My algorithm can split itself up, to proceed asynchronously using asap, however doing this every time slows down execution massively. I would like to have a (fast) way to find out the current stack usage percentage, so my algorithm can decide to continue synchronously if it is below like 90%, but continue asynchronously when it gets above. I know this value must be around internally, but is there a way to access it?

On the other hand I could imagine to catch the maximum stack size exceeded error, but I read here, that this is not possible (why not? Throwing this exception would mean returning to the caller, which should actually reduce stack size and the older stack entries should still be intact for doing this???)

Of course one way would be to pass a counter variable through all of my functions but this is awkward. Also it is unclear, at which counter value my stack is at 90%, because I do not know, how big the stack is and how big each of my stack frames is.

So actually it seems that JavaScript is born to fail in that case even though the programmer could avoid it, if he had access to the information he needed - which is present somewhere but kept secret for unknown reasons?

Michael K
  • 1,070
  • 1
  • 10
  • 25
  • Please show your work. This sounds like an issue with your algorithm, not how the javascript interpreter is running it. What are you running this on? Node or a browser? What is your algo even trying to accomplish? We need these details. – Soviut Jun 24 '17 at 05:08
  • I cannot provide "the algorithm" - it processes data and buils itself up recursively depending on the data. There is not an issue with my algorithm. When the data structure is nested deep enough, which happens in practice, stack will run over without having an endless recursion. – Michael K Jun 24 '17 at 10:18
  • If your recursion is going so deep that it's overflowing the stack, you need to rewrite your algo so do short tail recursion. – Soviut Jun 24 '17 at 16:50
  • Thats written in my question - i am aware of that. And I can split, it was just the question "when". But as you can catch the max call stack exceeded exception, 'when' becomes easy now... – Michael K Jun 25 '17 at 05:52
  • That's a horrible way to deal with this problem; Write your algo properly; Don't rely on wacky system quirks to cope with your inefficiencies. Write defensibly, instead of offensively. – Soviut Jun 25 '17 at 09:20

2 Answers2

2

There is no way to measure the current stack utilization without tracking it yourself, by passing a variable along or possibly referring to shared state.

But you can just catch the call stack overflow error when it gets full. (The unclear question you linked was talking about something else, I've written a new answer to clarify.) You could use this to get a rough idea of the available stack size, but that probably isn't guaranteed to be consistent for different functions depending on optimizations and stuff.

var maxDepth = 0;
function popTheStack() {
  maxDepth++;
  popTheStack();
}

try {
  popTheStack();
} catch (ex) {
  console.log("caught " + ex + " at depth " + maxDepth);
}
Jeremy
  • 1
  • 85
  • 340
  • 366
  • 1
    Did not read that other question well enough. I will do a jsperf, to see, how much introducing try catch blocks in my algorithm affects performance. – Michael K Jun 24 '17 at 10:15
1

It depends on browsers. Your approach isn't a best choice for a problem, of course we can not announce to users like " your request is too heavy and we cant handle it". Another approach is de-recursive the algorithm, all recursive solutions will always have a corresponding non-recursive one. You can simulate a stack by your own, rather than system stack, and implement looping to find the result.

Nhon Dinh
  • 221
  • 1
  • 5