Hi Sangamesh,
I should probably also read all of the code involved, properly, which I must admit I haven't, but based on general knowledge, my replies are:
On Tue, Mar 22, 2016 at 10:22:59AM +0000, Sangamesh Sajjan wrote:
The proposed structures are being used in following scenario. 1. System Init (i.e. During system bootup)
- Array of strings are used to form a tree, it is used only once during system bootup , hence it should not impact the performance. Let me know your opinion on this ?
Ok, for once-upon-boot a string approach sounds fair enough.
2. Decoding of EGPRS packet downlink Ack/Nack
- While decoding there is no string comparison involved, we read every bit from the bitmap and traverse tree generated in init, hence only bit operation involved in decoding.
sounds good
3. Encoding of packet uplink Ack/Nack
While encoding, first find the number of one's/zero's (i.e. run length of one's or zero's) consecutively and find the corresponding code word by referring to the code word list- This involves string comparison to find the code word,
Ick! :)
but based on your feedback we are planning to avoid string operations and adopt existing (i.e. master ) approach to find the code word by using respective tables.
Sounds much better, yes.
In current master code for decoding, the function t4_rle_term is used to find the run length for each received code word, There could be multiple code words in the received bitmap and each require multiple iterations(i.e. maximum of 64 iterations) to find run length. Instead if tree based approach is used multiple iterations can be avoided to find run length.
Is this a separate suggestion to introduce a binary tree search? Beware of too heavy / premature optimizations, but your trajectory sounds way better now.
Anyway, looking forward to the patches, and I hope to read the patch context properly, then. Thanks!
~Neels