> On Nov 5, 2015, at 2:43 PM, David M. Lloyd <david.ll...@redhat.com> wrote: > > On 11/04/2015 07:15 PM, Mandy Chung wrote: >> [...] >> For short-circuiting, I also think it’s reasonable to expect the user know >> how many remaining frames it expects to traverse and it may not need to >> increase the batch size i.e. it might not need to update the remainingNeeded >> over time. The user to supply the estimate number of frames needed may be >> adequate for it (like what you suggest previously having the walk method to >> take an initial batch size for the simple case). >> >> Walking the entire stack (or almost all stack frames) is the use case that >> this hint may help in performance since the stack depth is unknown and >> it’s a tradeoff between memory and runtime. Throwable::init and >> AccessControlContext are the use cases that need to be performant. It’s >> better to wait for more experience of using the StackWalker and see if any >> other use cases need adaptive sizing . I propose to drop this >> walk(Function, IntUnaryFunction) for now and decide to add such ability >> later. > > Yeah I agree, and furthermore I strongly suspect that there is only one > "best" batch size for the majority of whole-stack traversals. > >> For taking the estimated number of consumed frames, one option is to have a >> walk(int initialFramesNeeded, Function function) method. The other option >> is to have the >> StackWalker(int minDepth, int maxDepth, Set<Option> options) >> >> It’s cheap to have one StackWalker for each kind of stack walking. Having >> the constructor to take an additional minDepth (or estimate minimum number >> of frames to be traversed) seems a better option. >> >> Any thought? > > That seems like a reasonable hint to expect of the user, as long as it *is* a > hint and not a hard limit, and even better if the hint is optional.
Yes that’s what I propose - it’s a hint and also optional thanks Mandy
