Bulk mode for thread/goroutine stacks

[Dmitry Neverov]

Would it be possible to add an ability to retrieve stacktraces in bulk mode?

I'd like to build a UI for stacktrace analysis, currently one have to retrieve stacktraces one by one. Maybe additional options in ListGoroutinesIn, something like FillStacktraces (false by default) and AncestorsCount (0 by default)?

[alessandr...@gmail.com]

I don't think it's a good idea to make the API less orthogonal.

> --
> You received this message because you are subscribed to the Google Groups "delve-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to delve-dev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/delve-dev/46d128a6-7bfe-4608-9678-4628de6e52e9n%40googlegroups.com.
>

[Dmitry Neverov]

Is a dedicated bulk API call a better idea?

[alessandr...@gmail.com]

Is your thinking that you will get better performance? Because my guess is
that you won't.

[Dmitry Neverov]

Yes I was hoping it will improve performance. I've built a version which dumps stacks one by one and it tooks around 10 seconds to get ~7000 stacks on a local windows machine. I've used this version to dump delve goroutines while it computes the stacks and the busy goroutine always has a prefix like this:

  ...
  github.com/go-delve/delve/pkg/proc.GetG(variables.go:240)
  github.com/go-delve/delve/pkg/proc.FindGoroutine(variables.go:394)
  github.com/go-delve/delve/service/debugger.(*Debugger).Stacktrace(debugger.go:1353)
  github.com/go-delve/delve/service/rpc2.(*RPCServer).Stacktrace(server.go:190)
  runtime.call64(asm_amd64.s:520)
  reflect.Value.call(value.go:447)
  reflect.Value.Call(value.go:308)
  github.com/go-delve/delve/service/rpccommon.(*ServerImpl).serveJSONCodec.func2(server.go:311)
  github.com/go-delve/delve/service/rpccommon.(*ServerImpl).serveJSONCodec(server.go:31)

I thought it would be possible to dump goroutines once using proc.GoroutinesInfo and then fill the stacks without calling proc.FindGouroutine. Since stacks usually contain a lot of repeated file and function names, maybe a bulk api call can send them separately and stacks can use ids instead?

Also I wonder why proc.GoroutinesInfo doesn't use cached goroutines if  the start is 0  and count is less than the size of cached goroutines? 

[alessandr...@gmail.com]

Interesting! Can you try https://github.com/go-delve/delve/pull/2118 and see
what the bottleneck is then?

[Dmitry Neverov]

It works faster, now the busy goroutine is in G.Stacktrace as one would expect.