All good. I still think that the hack of blocking and restoring the runtime's SIGPROF signal handler might actually work though. It might not work. But if it does, it is almost exactly what you were looking for.
Ian or others more knowledgeable myself might be able to advise better if it _should_ work, but maybe give it a shot. You could ask on gopherslack too for ideas. On Wed, Nov 13, 2024 at 12:55 PM Stephen Illingworth < stephen.illingwo...@gmail.com> wrote: > On Wednesday 13 November 2024 at 12:02:12 UTC Jason E. Aten wrote: > > > I've tried but this unfortunately, the Start and Stop processes are too > expensive and really require writing to a different file for every stop. > The nature of the program means I need to do the Start/Stop process 60+ > times per second, so it would generate a lot of files and be very slow on > top. > > Note that the StartCPUProfile call takes an io.Writer. Therefore a simple > *bytes.Buffer suffices. No files need be created. You can be much faster > than the file system. > > > Yes. I've tried that too. But it's the call to StopCPUProfile() which > takes a lot of time. Using a bytes.Buffer it takes over 200ms to complete. > It's not much quicker than using a os.File as the writer implementation. > > My deadline for everything is less than 16ms so the 'pausing' process > needs to take a lot less time than that. > > I could maybe live with the delay for benchmarking purposes but I'm also > left with the problem of "concatenated profiles". pprof doesn't support > that. If it did or if there was a way of post-processing the concatenated > profiles into one profile that might be a satisfactory outcome. > > > > func StartCPUProfile(w io.Writer) error > > Writing a benchmark for your subsystem is the hardest mentally, but most > likely the best choice for the long term. > > > You're absolutely right of course. But I was hoping for a mechanism that > could be activated when a user detects a problem with their own input data. > That might still be possible but I'll have to give it some thought. > > Thanks for the reply! > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/Emrx_W9eSig/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/cd406d0c-c281-4e8f-99ac-6ffb5b3a16efn%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/cd406d0c-c281-4e8f-99ac-6ffb5b3a16efn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAPNEFAYSGUGx2S6P9Mr4poOzBNSZ5u-4pBKcwMuHdCza76n8OQ%40mail.gmail.com.
