> I'm wondering how easily we'll introduce bugs in that way I've just realized that using enableunsafedecode=true would prevent us from pooling the buffers, as whenever using unsafe.Pointer to convert between []byte and string one cannot modify the original []byte array. I'll update the pooling benchmarks to reflect this.
>What's the gain by using the flag vs. not using it? In general, using the safe method seems to degrade performance by ~10%, while still saving ~10% of memory. Unsafe would keep the same performance and save roughly ~30% memory. Using safe unmarshaling and pooling both compressed and uncompressed buffers seems to be the best way forward - although I would like to get a double-check from someone regarding the benchmarks results. Q: is there any reason why Prometheus already doesn't do this? It seems like the only place where buffers are pooled is for marshaling remote write responses. >How confident can we be that csproto will be consistently maintained? The nice thing about both csproto and vtproto are that they both leverage the structs generated by the default google implementation and override the Marshal and Unmarshal methods. This would mean that the biggest work would have to be done to migrate from gogo to either one of these two implementations, while switching from csproto to vtproto would be trivial, as they implement virtually the same interface. Even if csporto and vtproto were to be discontinued in the future, I think most protobuf alternative implementations would continue onto this path. On Thursday, February 15, 2024 at 4:12:51 PM UTC+1 Bjoern Rabenstein wrote: > Thanks for doing this. > > Beyond benchmarks, two general concerns: > > - How unsafe is `enableunsafedecode=true`? I spot-checked the csproto > code, and the risk seems to be on the side of the user code, > i.e. luckily there isn't any unsafe input, but I'm wondering how > easily we'll introduce bugs in that way. What's the gain by using > the flag vs. not using it? (FTR, the Prometheus code is using the > same trick with the `yoloString` itself, but that has also been > frowned upon...) > > - How confident can we be that csproto will be consistently > maintained? It seems to be mostly the work of a single person, and > it is sponsored by a single company (which is at least already 13 > years around, and has 7k employees, so probably not disappearing > tomorrow). > > Not saying these are blockers, just trying to come to an informed > decision. > > -- > Björn Rabenstein > [PGP-ID] 0x851C3DA17D748D03 > [email] bjo...@rabenste.in > -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/6656d04d-a5c0-4a6e-9714-1aaee35b3f4cn%40googlegroups.com.