| 00:02.09 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-sskjnziezhjkxkbk) |
| 00:05.08 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00884dc7d7cc412b2b.ipv6.abo.wanadoo.fr) |
| 00:11.57 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 01:20.16 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 01:20.16 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 01:59.22 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00ad055a836359153b.ipv6.abo.wanadoo.fr) |
| 02:22.08 | *** join/#asterisk-dev mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 02:22.08 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 04:00.27 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d007025b44d38ce3461.ipv6.abo.wanadoo.fr) |
| 06:38.38 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0004920721163c40bf.ipv6.abo.wanadoo.fr) |
| 06:54.40 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00c18ffa61e923eb87.ipv6.abo.wanadoo.fr) |
| 09:00.22 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d003d38fcef76d65e8f.ipv6.abo.wanadoo.fr) |
| 09:14.13 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d004c4c7cfdf33ae795.ipv6.abo.wanadoo.fr) |
| 09:30.42 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0061afdbdf6cf89794.ipv6.abo.wanadoo.fr) |
| 09:54.47 | *** join/#asterisk-dev mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 09:54.47 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 10:08.40 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0051eb14270115726e.ipv6.abo.wanadoo.fr) |
| 10:10.59 | tzafrir | Just to repeat what I wrote on the users list: Is there any noticeable performance impact for enabling BETTER_BACKTRACE (without DONT_OPTIMIZE)? |
| 10:11.17 | tzafrir | Does it help? |
| 10:30.00 | mvanbaak | hey tzafrir |
| 10:30.16 | tzafrir | mvanbaak, hi |
| 10:30.45 | tzafrir | GTG |
| 10:30.50 | mvanbaak | laters! |
| 11:03.38 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 11:24.21 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 11:33.10 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 16:07.09 | coreyfarrell | tzafrir: BETTER_BACKTRACES only touches the code related to generating backtraces. it adds overhead to the function that generates backtraces, unless you are logging a ton of backtraces it won't matter. |
| 16:11.33 | coreyfarrell | tzafrir: I should clarify that I only assume it adds overhead to generating a backtrace, I've never actually tested performance of one vs the other. |
| 16:48.11 | coreyfarrell | also looks like MALLOC_DEBUG internally generates a backtrace for every allocation, but if you've enabled MALLOC_DEBUG then performance is already :( |