So the perf win (in theory) is about offloading the serialization step/persistence to a background thread. Since that's already happening there makes sense to zero it out before returning it back to the original thread to do something with. And I realize maybe it's possible to not actually need a serialization step since in theory it should be "free" but it looks like there's not built-in APIs that provide this?
The general theory of the system is to have 2 TLS buffers so that the "fast-path" for storing an event doesn't need to acquire any locks or anything. Just save some data into RAM. When TLS buffer fills up we notify the background thread that this buffer should be flushed and then switch to the other TLS buffer (which currently requires taking a lock but could be lock free later) If you have any tips on better approaches to try that would keep the trace point even more minimal cost than this would gladly accept your input. On Wed, Aug 21, 2019 at 11:20 AM Kenton Varda <ken...@cloudflare.com> wrote: > Hmm, is it actually a performance win to offload memory-zeroing to another > thread? I would think moving the cache lines between the two cores would > cost more than the zeroing itself. > > -Kenton > > On Wed, Aug 21, 2019 at 11:05 AM Vitali Lovich <vlov...@gmail.com> wrote: > >> Oh. I'm very wrong. The check is in MallocMessageBuilder. I'll try my >> custom builder. >> >> On Wed, Aug 21, 2019 at 11:03 AM Vitali Lovich <vlov...@gmail.com> wrote: >> >>> I have not. I thought MessageBuilder constructor requires zero'ed memory >>> so this kind of split construction to "resume" the arena isn't possible >>> with a custom subclass but maybe I'm wrong? >>> >>> And yes I agree that I need to zero that memory but I do that on a >>> background low priority thread after I serialize (the goal is to offload as >>> much as possible and capture/write only the unique data that's >>> irreplaceable at the tracepoint). For example I even avoid capturing the >>> TID at the tracepoint because that's implicitly available when I submit >>> that threads events for serialization. >>> >>> On Wed, Aug 21, 2019 at 10:46 AM Kenton Varda <ken...@cloudflare.com> >>> wrote: >>> >>>> Hi Vitali, >>>> >>>> Instead of using MallocMessageBuilder, have you tried writing a custom >>>> subclass of MessageBuilder? It should allow you to customize these things >>>> more precisely. >>>> >>>> Note that *someone* has to zero out memory before Cap'n Proto can start >>>> allocating from it (because Cap'n Proto structures all expect to be >>>> zero-initialized anyway, so as an optimizaiton we assume memory is zero'd >>>> in advance), but with a custom MessageBuilder you have more control over >>>> when it happens. >>>> >>>> -Kenton >>>> >>>> On Tue, Aug 20, 2019 at 7:53 AM Vitali Lovich <vlov...@gmail.com> >>>> wrote: >>>> >>>>> Hi, I'm trying to use cap'n'proto as want efficient in-memory store of >>>>> events that adds as little overhead as possible to the act of creating an >>>>> event. Where I'm at is that I have per thread buffers that I in-place >>>>> allocate a MallocMessageBuilder into a 512 buffer and use the remainder as >>>>> scratch. I then defer serialization and destruction onto a background >>>>> thread that flushes when there is a listener for the event (no listeners >>>>> registered, simply overwrite). This works fine and performs fairly well >>>>> (~300ns overhead per event on PC, maybe 1000ns on Android). >>>>> >>>>> Is there a way I can write a builder to live on the stack and not >>>>> allocate it in the ring buffer in this setup? The challenges I ran into >>>>> are >>>>> that the builder zeroes on destruction and mandates that it's initialized >>>>> with zeroed memory. >>>>> >>>>> I'm ok if this adds a restriction on the available arena size which I >>>>> don't actually have now (since the builder itself is *very* at 200+ bytes >>>>> relative to the events). I would still like to be able to add more data to >>>>> the message in the background thread like I do now (eg process name, pid, >>>>> etc) that is event-agnostic and can be cheaper to defer filling that in to >>>>> the background listener delivery thread. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Cap'n Proto" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to capnproto+unsubscr...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/capnproto/CAF8PYMg54h9js%2BRiVhx4TA4DKiLty8iLZiRCUc21iKbmq7fhDQ%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/capnproto/CAF8PYMg54h9js%2BRiVhx4TA4DKiLty8iLZiRCUc21iKbmq7fhDQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "Cap'n Proto" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to capnproto+unsubscr...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/capnproto/CAF8PYMj435gc8xEgKS%3D%2BD%2BOiAFwTPfejiLHTM%3Dv%3D7cZkGYTkQA%40mail.gmail.com >> <https://groups.google.com/d/msgid/capnproto/CAF8PYMj435gc8xEgKS%3D%2BD%2BOiAFwTPfejiLHTM%3Dv%3D7cZkGYTkQA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAF8PYMi2e52Yq4wTntDC3ojY2eF_G1VTWrrWHWtd0hjoyBVv2Q%40mail.gmail.com.
