Idea 0: Can you just click on the graphviz boxes in the pprof http page for your section and then just show the source for only those? Might give you a quick idea of which are the hottest spots only among those func of interest.
Idea 1: Can you write a test or benchmark that just exercises the important section? I suspect you could then run the profiler on your benchmark/test. If not, it might be worth refactoring your code to allow this. Otherwise you could write an alternative "main" as a harness that just calls the important section. Idea 2: referring to the StartCPUProfile docs: > On Unix-like systems, StartCPUProfile does not work by default for Go code built > with -buildmode=c-archive or -buildmode=c-shared. StartCPUProfile relies on the > SIGPROF signal, but that signal will be delivered to the main program's SIGPROF > signal handler (if any) not to the one used by Go. To make it work, call os/signal.Notify > for syscall.SIGPROF, but note that doing so may break any profiling being done by the main program. This makes it sounds like the SIGPROF signal is used to do the sampling. So you might be able to manipulate it (e.g. ignore it when not in your code). Seems like a hack, but might be worth experimenting with. Idea 3: post processing. You could probably take apart the profile log after it is recorded and discard the samples that are irrelevant. Idea 4: simple manual timing. Insert time.Now() and time.Since() calls at strategic points, and measure the improvement as you tweak your code. On Tuesday, November 12, 2024 at 11:16:56 AM UTC Stephen Illingworth wrote: > Hello, > > I want to create a runtime CPU profile but to restrict the profile to a > specific part of the program. I currently have a way of taking a CPU > profile for the entire program so have experience with the runtime/pprof > package but this is a new requirement for me. > > The 'section' to be profiled represents a significant amount of code and > I'm looking to see if any particular part of that section can be improved. > The problem I have is that the program outside of that section is > significantly larger (ie. larger CPU load) and dominates the profile data. > > The section to be profiled is entered and exited 60 times per second (at a > minimum). > > In effect, I want to pause the CPU profile when execution exits the > section and to resume when the profile enters it again. Stopping and > restarting the profile is too slow. > > But maybe there's a completely different way to do this. Does anyone have > experience with this type of thing? > > Regards > Stephen > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/c6c0833e-a1d0-4132-87cf-c03b7f6a0ab6n%40googlegroups.com.
