Hi Harald,
When I look at the current API, the decode_init()/decode_deinit() functions are great candidates to perform such allocation/release of memory. If applications use the osmo_conv_decode() convenience wrapper, it simply means they don't care about efficiency, but if they use the real init/scan/flush/deinit API, they would benefit from it.
You are talking about Sylvain's implementation of Viterbi, which is currently used as fail-safe back-end for a new algorithmically and SIMD optimized implementation, written by Tom Tsou.
In the Sylvain's implementation (conv.c), init/scan/flush/deinit are exposed for external usage, meanwhile Tom's implementation is transparently integrated into the first one, and doesn't expose anything outside.
The viterbi.c code (which by the way chould be renamed to conv_acc.c or the like) would then have to be restructured to plug into init/fini for allocation+release.
Do you suggest to expose alloc_vdec, free_vdec and osmo_conv_decode_acc like it is done in the conv.c?
Anyway, using init/fini is profitably only if you are doing serial (en/de)coding of the same convolutional code. As soon as you need to (en/de)code another convolutional code, you will have to reallocate and reconfigure the vdec object.
(which by the way chould be renamed to conv_acc.c or the like)
I like this idea, already in my TODO list :)
I doubt this will improve your speed. Feel free to try, but this is more of a clean-up to ensure all the memory allocated within osmocom projects is tracked/accounted for, and you can get talloc usage reports, debug memory leaks, etc.
Agree with you. But what do you think about talloc memory pools?
With best regards, Vadim Yanitskiy.