On Sep 30, 2010 at 20:07, Daniel-Constantin Mierla miconda@gmail.com wrote:
I was checking what are current differences between the two major flavours: ser and kamailio.
Apart of the name and default config file, kamailio flavour enables at compile time KMSTATS, FMSTATS and WITHAS, precisely these are:
ifeq ($(KMSTATS), 1) C_DEFS+= -DUSE_CORE_STATS -DSTATISTICS endif ifeq ($(FMSTATS), 1) C_DEFS+= -DMALLOC_STATS endif ifeq ($(WITHAS), 1) C_DEFS+= -DWITH_AS_SUPPORT endif
I am thinking that maybe we can make them (all or some) enabled by default now that Andrei added the new statistics API.
Yes, but they are not yet used everywhere.
From the point of view of core and common modules (modules/):
USE_CORE_STATS will enable event callbacks (sr_event_exec) _for_ _each_ use. I don't have anything against migrating them to use directly counters and then having them enabled by default (right now they do all this extra stuff that is not needed anymore).
STATISTICS seem to enable only the statistics inside modules/sl. While module/sl could also be migrated to counters (very easily, only the help text would need some time), the performance impact is almost non-existent so I have nothing against enabling it.
WITH_AS_SUPPORT enables extra api in TM, iirc this would be needed at least by seas module.
That I am not sure. I don't think that the 1 or 2 modules that need it justify having it enabled by default (for one thing the transaction size will slightly increase). So far my impression is that modules that depend on WITH_AS_SUPPORT are seldom used, in specialized application (but please correct me if I am wrong).
Anyone with pro/cons?
Speaking of statistics we could try re-enabling stats.[ch] (after re-basing it on counters), and updating tm stats, dns stats and sl stats to use counters (it would be nicer to have all the stats from the same interface, with associated help and auto-generated documentation). Unfortunately I don't think we have time for it (leave them for 3.1.1 ?).
Andrei