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