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 <[email protected]> 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 <[email protected]> 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 [email protected]. >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAF8PYMgcYpCzzGTn%3D2BCiP9TB%3D7nH8Uv2PTK6hdz6R03kQY43Q%40mail.gmail.com.
