RFC adding another debug log statement

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

noselasd at fiane.dyndns.org noselasd at fiane.dyndns.org
Tue Dec 31 02:57:40 UTC 2013


On 12/30/2013 10:55 AM, Holger Hans Peter Freyther wrote:
> Good Morning,
>
> during the 30C3 we had some "broken channels" because the BTS didn't
> respond within four seconds to a Channel Activation/Deactivation. I
> started to look at it with perf and "snprintf" appears to be called a
> lot and did show up in the top.
>
> snprintf is mostly called from within osmo_hexdump and gsm_lchan_name.
> Both of these function calls are used in our logging calls throughout
> the code.

Would it be worth it to get rid of snprintf in osmo_hexdump ?
Anecdotally I've converted similar code away from snprintf to a more raw
variant resulting in a 7-8 times speed increase of the program whose
main purpose was to hex encode messages.

see attached patch for an example
(it may now truncate the hex dumps at a byte boundary vs at a nibble 
when using snprintf if the hex exceeds sizeof(hexd_buff) though)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libosmocore_faster_hexdump.patch
Type: text/x-patch
Size: 996 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20131231/587fc78a/attachment.bin>


More information about the OpenBSC mailing list