

Profiling Go Programs - alexandere
http://www.slideshare.net/cloudflare/go-profiling-john-graham-cumming

======
collinvandyck76
One thing I find frustrating about the net/http/pprof package is its init
method, which does:

    
    
        http.Handle("/debug/pprof/", http.HandlerFunc(Index))
        http.Handle("/debug/pprof/cmdline", http.HandlerFunc(Cmdline))
        http.Handle("/debug/pprof/profile", http.HandlerFunc(Profile))
        http.Handle("/debug/pprof/symbol", http.HandlerFunc(Symbol))
    

In my particular case, I wanted all normal application traffic to be handled
by my 8080 handler, and the /debug/* traffic handled by another listener on
port 6060. Even if I explicitly link the above handler functions into my port
6060 ServeMux, because of the init() method it still registers across all of
my handlers. I.e. port 8080 and 6060 both respond to, for example,
/debug/pprof/cmdline.

~~~
stevvooe
Create a separate ServeMux for your application and let the utilities register
to the DefaultServeMux via init (and you can even register your own!). Bind
the DefaultServeMux to the debug port (6060) using
http.ListenAndServe(debugPort, nil) and bind your app to its port (8080) with
http.ListenAndServe(appPort, appMux).

~~~
collinvandyck76
This worked great, thanks.

------
jamra
I really like the usefulness of the pprof tool. I also like Rob Pike's book
"The Unix Programming Environment". It's clear that Mr. Pike likes small
command line programs that do an isolated task well.

I just wonder if it could be more beneficial to the community if Google
invested in an IDE with a GUI for all of these tools.

------
pkroll
Slide incorrectly attributes the "premature optimization" quote to Hoare, but
it's Knuth's. [http://hans.gerwitz.com/2004/08/12/premature-optimization-
is...](http://hans.gerwitz.com/2004/08/12/premature-optimization-is-the-root-
of-all-evil.html)

------
staunch
Just recently felt the need to profile a tiny little Go program that I
converted from Perl. Found out just how damn fast Perl's (C-based) regular
expressions are. Go's Regexp library is absolutely awesome, but in this
specific case significantly slower. Profiling was a piece of cake.

~~~
chimeracoder
If you've already done the profiling, you're probably already aware of this,
but for anybody else:

Go uses RE2, not PCRE (which Perl uses, obviously) for regular expressions:
[https://code.google.com/p/re2/](https://code.google.com/p/re2/). There is
also a third-party PCRE library for Go somewhere, though the standard library
uses RE2.

One of the advantages of RE2 is that it guarantees that the regular expression
runs in linear time (in the length of the input), unlike backtracking-engines
like PCRE (which are provably undecidable, like the halting problem).

However, aside from not supporting backtraces, it also can be slower on
certain kinds of regexes and inputs.

As always, the best (only?) way to know which approach is better is to test
(profile) - which, I agree, is a piece of cake in Go.

~~~
pcwalton
Perl doesn't actually use PCRE by default, though it's an option in 5.10.

Incidentally, one of the reasons that PCRE is faster is that it uses a JIT in
newer versions.

------
ushi
For interested people: Here is the discussion about the mentioned pool
package:
[https://code.google.com/p/go/issues/detail?id=4720](https://code.google.com/p/go/issues/detail?id=4720)

------
johnarnow
Does anyone have a link to download the slides? Slideshare apparently doesn't
believe people can exist without either a Facebook or LinkedIn account or
both.

~~~
kcen
Looks like you can sign up just fine with only an email address.

------
babawere
Good Slide .. has anyone seen the video ?

