Implement telemetry:persist/0#144
Conversation
This is preliminary step towards implementing beam-telemetry#142. This allows using unnamed table and provide a way to swap implementation for more performant one.
21c2f13 to
3246db5
Compare
|
@hauleth another approach would be to keep the persistent term and ets and dynamic registrations after locking still goes to ets. But maybe the double lookup makes everything worse. |
|
Yeah, that would mean that we still need to pay ETS tax. |
|
I am not sure if there should also be "unlock" function to go back to ETS-based implementation. |
|
I don’t think there is a need right now. But we should probably add a flag to tests so we run the suite in both modes. I am also not very happy with the name “lock”. We could try “persist”, “consolidate”, or something of sorts. |
|
@josevalim I do not like the name It is tested in both modes. Only thing not tested for now is what happens when mode switches from one to another. |
This adds new `telemetry:lock/0` function that allows locking telemetry handlers to improve execution performance at cost of slowing down attaching and detaching handlerrs.
3246db5 to
3067d4a
Compare
|
Please give it a try and let us know once you have some data. Once we release a new data, we probably want to enable this by default in Phoenix! |
This new function adds support to "lock" the handlers. Locking handlers will improve performance of execution at the cost of attaching/detaching handlers.
Locked performance shows about 7% improvement in my Peep benchmark
This is just an initial implementation as PoC.
Close #142