On Mon, Oct 21, 2019 at 10:26 PM wrote:
>
> I'm trying find the memory usage of a hashmap?
>
> I've got the most of the pointers for calculating memory usage from this
> issue https://github.com/golang/go/issues/34561
>
> But, I don't know how many buckets that hashmap using to get the accurate
Example https://github.com/gertcuykens/module/tree/v4.0.0 can I assume it
to be good practice to put a empty go.mod file in the root directory that
doesn't contain other go files, only the version folders, so the root
itself doesn't get recognised as a module itself?
--
You received this mess
Thanks Chris
On Monday, October 7, 2019 at 10:40:22 AM UTC-7, Chris Hines wrote:
>
> I am pretty sure that a "proc" in the trace visualization output is the
> same as a "P" in the parlance of the Go runtime scheduler. In the scheduler
> an OS thread is an "M" and even when using LockOSThread the
On Mon, Oct 21, 2019 at 11:26 PM wrote:
>
> Code:
> func main() {
> s := "hello world"
> b := []byte(s)
> c := make(chan []byte, 1)
> e := make(chan bool)
>
> f := func() {
> d := make([]byte, 3)
> fmt.Println("buff size: ", len(d))
> for {
> fmt.Println("loop ...")
> fmt.Println("chan c size: ",
Hello Gophers!
I'm trying to migrate some code that uses `reflect.Type` at runtime to
`types.Type` from `go/ast` built ahead of time. I got a pretty good way
(converted all the code and got it to successfully compile,) until I
realized that I hadn't been clearly thinking about the
`reflect.Ty
Code:
func main() {
s := "hello world"
b := []byte(s)
c := make(chan []byte, 1)
e := make(chan bool)
f := func() {
d := make([]byte, 3)
fmt.Println("buff size: ", len(d))
for {
fmt.Println("loop ...")
fmt.Println("chan c size: ", len(c))
select {
case d = <-c:
//c <- []byte{100, 101}
//d := <-c
fm
Hi,
I'm trying find the memory usage of a hashmap?
I've got the most of the pointers for calculating memory usage from this
issue https://github.com/golang/go/issues/34561
But, I don't know how many buckets that hashmap using to get the accurate
result?
--
You received this message because
Thanks for the clarification Than & Robert,
I think I'm understanding how to read the tree now. In order to discern the
call hierarchy
for an entry,I look at the caller/s and then can search the tree for the
caller/s and then
look at the caller's caller/s... etc.
One thing that is still puzzling
Yes, that’s what I was referring to. It is much easier then the graph in some
cases.
Also github.com/robaho/goanalyzer might help depending on the workload
>> On Oct 21, 2019, at 2:10 AM, Than McIntosh wrote:
>
> It can sometimes be useful in such situations to look at the pprof "tree"
> o
The "tree" output format is modeled approximately after the output of the
ancient unix tool "gprof" (see
https://ftp.gnu.org/old-gnu/Manuals/gprof-2.9.1/html_chapter/gprof_5.html).
For tree output, you'll see entries of the form
Caller(s)
Function
Ok, Thanks.
On Mon, Oct 21, 2019 at 5:42 PM Ian Lance Taylor wrote:
> On Mon, Oct 21, 2019 at 4:38 AM Nidhi Agrawal
> wrote:
> >
> > Ok, Also is there any harm if we set block/mutex rate at the start of
> the program ? Will it cause any memory allocations or any kind of
> performance impact?
>
On Mon, Oct 21, 2019 at 4:38 AM Nidhi Agrawal wrote:
>
> Ok, Also is there any harm if we set block/mutex rate at the start of the
> program ? Will it cause any memory allocations or any kind of performance
> impact?
It will cause some additional memory allocations as the program
records profil
Ok, Also is there any harm if we set block/mutex rate at the start of the
program ? Will it cause any memory allocations or any kind of performance
impact?
On Mon, Oct 21, 2019 at 2:47 PM Ian Lance Taylor wrote:
> On Sun, Oct 20, 2019 at 8:57 PM Nidhi Agrawal
> wrote:
> >
> > Implementation in
Hi Than,
Thanks for the tip.
I actually discovered that selecting a node and using the Focus option from
the Refine in
the web view gets me a clear view of the callers and callees for the
selected node.
I have tried the tree view, passing the focus option on the command line
but I' don't underst
On Sun, Oct 20, 2019 at 8:57 PM Nidhi Agrawal wrote:
>
> Implementation in http/net/pprof library is leading me to conclude that they
> are different.
> Yes, In runtime/pprof block, mutex, cpu all are implemented in the same way,
> but http/net/pprof is not using them in the same way.
> In CPU p
It can sometimes be useful in such situations to look at the pprof "tree"
output style (as opposed to graph).
Than
On Sat, Oct 19, 2019 at 4:14 AM Piers Powlesland
wrote:
> Kind of, but due to the sheer number of nodes and edged the edges end up
> lying on top of each other so in certain cases
16 matches
Mail list logo
