[srslte-users] usage of std map vs unordered_map and operator[]

[J Giovatto]

Hi folks,

I've noticed some extensive use of std map operator map in the "go
path", in the enb  phch_worker.cc phch_worker::decode_pusch for one.

Please understand that this is purely a FYI, as I'm not trying to
criticize or claiming that this is an an all out error, but this could
lead to additional over head and/or undesired behaviour.

One downside is that a check is made for the key each time that
operator[] is used, this could result in additional over head of O
log(n) each time vs

using a reference to the element once it is found...

MapType::iterator itr = map.find(key);

if(itr == map.end())

  itr = add_element_or_throw_exception_depending_on_case(key);

else

ElementType & e = itr->second;

// now freely use e.


The other possible downside is that a "default" entry will be made if
the key is not found, this may or may not be what you

want and it NOT obvious when an key exists and "add()" is called vs a
key does not exist and some "update()" operation is called, some added
logs indicating this.

3:44:46.100155 [PHY0] [I] [00193] ue_db_is_ack_pending XXX not found
rnti 0x46, sf_idx 3, tb_idx 1, last_n_pdcch -1, no
13:44:46.100170 [PHY0] [E] [00193] decode_pusch XXX, rnti 0x46 NOT FOUND
!!!!! in ue_db size 12
13:44:46.100186 [PHY0] [I] [00193] decode_pusch XXX, rnti 0x46, cqi_en
no, send_cqi no, pmi_idx 0, tti_rx 193, cqi_value.type 0, cqi_enabled no
13:44:46.100199 [PHY0] [I] [00193] ue_db_set_last_ul_tbs XXX rnti 0x46,
tti 193, tbs 56
13:44:46.100210 [PHY0] [I] [00193] ue_db_add_rnti XXX rnti 0x46, does
not exist
13:44:46.100221 [PHY0] [I] [00193] ue_db_set_last_ul_mod XXX rnti 0x46,
tti 193, mcs 1

13:44:46.101281 [PHY0] [I] [00194] ue_db_add_rnti XXX rnti 0x46, !!!
DOES exist
13:44:46.102085 [PHY0] [I] [00195] decode_pucch XXX, rnti 0x46, pmi_idx
0, tti_rx 195, needs PUCCH no, needs cqi no
13:44:46.102963 [PHY0] [W] [00195] add_rnti XXX rnti 0x46 already exists

I've included a patch with the log changes that illustrate this.

Also some investigation could be made on using std::map and
std::unordered_map depending on lookup vs insertion/deletion frequency.

Regards

Joe

PS: an interesting write up on this topic below.

http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/2005/0504/0504j/0504j.html

https://stackoverflow.com/questions/2196995/is-there-any-advantage-of-using-map-over-unordered-map-in-case-of-trivial-keys

-------------- next part --------------
A non-text attachment was scrubbed...
Name: enb_log_additions.patch
Type: text/x-patch
Size: 17045 bytes
Desc: not available
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20180226/0343e5e7/attachment.bin>