(On gopherslack, the #darkarts folks are performance oriented....) On Wed, Nov 13, 2024 at 1:30 PM Jason E. Aten <j.e.a...@gmail.com> wrote:
> 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/CAPNEFAZ-Lxvn9%2BX6rdcH-oipAvBSzMSwt%2BdgBdiK9bnm_5LSMA%40mail.gmail.com.
