On Fri, Oct 5, 2018 at 10:12 AM Ralph Goers <rgo...@apache.org> wrote: > > On Oct 5, 2018, at 1:10 AM, Luke Hutchison <luke.hu...@gmail.com> wrote: > > > > On Thu, Oct 4, 2018, 10:27 PM Ralph Goers <rgo...@apache.org > > <mailto:rgo...@apache.org>> wrote: > > Yes, we have found in some situations using the SecurityManager is faster > > than StackWalker. > > > > This is interesting -- how much slower is StackWalker in these situations, > > and under what condition is there a speed difference? > > Benchmark Mode Cnt Score Error Units > StackTraceBenchmark.defaultJava8 thrpt 3 113965.921 ± 119706.986 ops/s > StackTraceBenchmark.securityManager thrpt 3 788004.237 ± 82578.567 ops/s > StackTraceBenchmark.stackWalker thrpt 3 182902.031 ± 39018.395 ops/s
Something to consider is _how_ the StackWalker is used. It's potentially quite expensive in that it produces a Stream in its full usage mode. Have you compared using the stream + lambda approach versus extracting the stream iterator and iterating in the classic Java fashion? I doubt it would make the benchmark competitive, but it might help a little bit. In the end, StackWalker does a relatively large amount of work and performs substantially more object allocations than the simpler classical approaches. Extracting any decent performance of StackWalker would probably be highly contingent on successful compiler optimizations like devirtualizing and inlining the stream processing, deleting unused allocations, etc. In practice these kinds of optimizations seem very finicky and quite easy to inadvertently defeat, which is why I've always been skeptical about the Stream approach. Maybe the iterator has potential to be slightly better, or could be made to do so. -- - DML
