| 00:15.18 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.23.116.90) |
| 00:49.01 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 00:50.28 | *** join/#asterisk-dev suneye (~atcmmi@119.139.61.138) |
| 00:55.51 | *** join/#asterisk-dev barbosa2 (~juliano.b@177.17.230.156.dynamic.adsl.gvt.net.br) |
| 01:07.01 | *** join/#asterisk-dev oej (~Adium@67.217.137.66) |
| 01:07.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 01:30.13 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.23) |
| 02:46.27 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.23.116.90) |
| 03:29.52 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.23.116.90) |
| 04:42.18 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 05:30.44 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 05:30.54 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 06:29.59 | *** join/#asterisk-dev atcmmi (~atcmmi@116.25.196.17) |
| 06:51.06 | *** join/#asterisk-dev danjenkins (~danjenkin@cpc3-folk2-2-0-cust34.1-2.cable.virginmedia.com) |
| 06:56.08 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.229) |
| 07:17.33 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 07:37.26 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 07:37.26 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 07:56.50 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:56.50 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:22.38 | *** join/#asterisk-dev suneye (~atcmmi@116.25.194.34) |
| 09:11.24 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.105.163.70) |
| 09:12.35 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 10:12.06 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 10:33.23 | *** join/#asterisk-dev barbosa2 (~juliano.b@177-069-248-123.static.ctbctelecom.com.br) |
| 11:15.07 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 11:50.08 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 11:53.25 | *** join/#asterisk-dev oej (~Adium@67.217.137.66) |
| 11:53.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:54.03 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.246) |
| 12:09.12 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:09.12 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:12.42 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:12.49 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:12.51 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:12.55 | italorossi | malcolmd: ping |
| 12:24.22 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 12:29.10 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 12:33.16 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:10b:5a72:6e1b:d858) |
| 12:46.53 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 13:02.17 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-jnsozlyrgwczwkgd) |
| 13:02.17 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:08.06 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 13:12.29 | *** join/#asterisk-dev Pullphinger (~Pullphing@12.40.23.68) |
| 13:12.43 | *** join/#asterisk-dev danjenkins_ (~danjenkin@213.106.234.250) |
| 13:16.00 | *** join/#asterisk-dev spditner (~simon@206-248-134-49.dsl.teksavvy.com) |
| 13:21.43 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-cnyuypgesubumjoq) |
| 13:27.43 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 13:34.28 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 13:40.15 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-atgueyvuynaeqgsa) |
| 13:57.27 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:57.27 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:01.02 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 14:12.20 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-kmzritfybybbtfxs) |
| 14:12.47 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:12.47 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:31.47 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 14:31.47 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:38.23 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.23.116.90) |
| 14:43.36 | *** join/#asterisk-dev barbosa2 (~juliano.b@177-069-248-123.static.ctbctelecom.com.br) |
| 14:51.38 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mdcsnvqeqzsyqsrm) |
| 14:51.38 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:04.18 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.105.163.70) |
| 15:21.00 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 15:46.38 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-vjmpeglsttqdrgfs) |
| 16:49.17 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-nsztjbboncccmrmm) |
| 16:49.17 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 17:25.46 | mjordan | so, apropos to our conversation of performance but also something that is now screwing up CDRs, I'm not sure the string container on bridges should be an ao2 container |
| 17:25.52 | mjordan | for determinism, you can't predict at all the ordering of the channel IDs in the container |
| 17:26.17 | mjordan | so in a multi-party bridge, we can't predict what order the channels are presented |
| 17:26.35 | mjordan | for performance, it's a container that is typically iterated upon, as opposed to looked up by key |
| 17:26.52 | mjordan | granted, it won't typically have a large number of channels in it, but it could in a confbridge |
| 17:27.14 | mjordan | although admittedly, the size is always 13 |
| 17:28.46 | mjordan | opticron: leedm777: file: anyone have any objection to converting the bridge snapshot's list of channels to an actual lsit? |
| 17:28.49 | mjordan | er, list? |
| 17:30.13 | file | hrm, no? |
| 17:30.20 | leedm777 | mjordan: is it the iteration of the AO2 container that's getting to you? |
| 17:30.20 | opticron | that should be fine |
| 17:33.12 | mjordan | leedm777: you can't predict the order of uniqueid's placed into an ao2 container with multiple buckets |
| 17:33.29 | mjordan | So when verifying records from a bridge with multiple channels, you can't... win. |
| 17:33.32 | mjordan | I could not play |
| 17:33.39 | leedm777 | mjordan: so you'll need a sorted list, then? |
| 17:33.51 | mjordan | doesn't even have to be sorted |
| 17:33.55 | mjordan | it just can't change the ordering on me |
| 17:34.03 | mjordan | if I put A in first, A should come out first |
| 17:34.17 | leedm777 | okay; you just need a stable order. |
| 17:34.19 | mjordan | Right now we put in A, B, C and get back A, C, B. Or C, B, A. Or who knows. |
| 17:34.20 | leedm777 | I'm all good, then. |
| 17:34.20 | mjordan | yup |
| 17:35.19 | mjordan | since this isn't a performance bottleneck, I may just change the bucket size to 1 |
| 17:35.26 | mjordan | we never look up by channel ID (yet) anyhow |
| 17:35.38 | opticron | also acceptable (and what I was thinking) |
| 17:36.55 | leedm777 | agrees |
| 17:38.19 | mjordan | cheers for consistency |
| 17:39.10 | file | mjordan, dream your dream... it's your dream, kid. |
| 17:40.21 | mjordan | is willing to sacrifice a lot for his dream |
| 17:40.26 | mjordan | LOCK ALL THE THINGS |
| 17:40.45 | file | IGNORE SIGSEGV! |
| 17:40.58 | mjordan | well, I wouldn't say ignore it. Just handle it gracefully |
| 17:41.17 | mjordan | you're okay with that memory address that doesn't belong to you. Just keep moving along |
| 17:41.33 | mjordan | is worried that someone will read this and believe him |
| 17:43.04 | leifmadsen | I'm in the middle of writing a blog post |
| 17:43.06 | file | mjordan, you should be worried... you should be |
| 17:44.52 | mjordan | btw, if you haven't read this, you should: https://www.usenix.org/system/files/1309_14-17_mickens.pdf |
| 17:45.09 | mjordan | "Modern software barely works when the hardware is correct, so relying on software to correct hardware |
| 17:45.10 | mjordan | errors is like asking Godzilla to prevent Mega-Godzilla from terrorizing Japan. THIS DOES NOT LEAD TO RISING PROPERTY VALUES IN TOKYO." |
| 17:46.47 | leifmadsen | haha |
| 17:55.53 | jrose_atDigium | is unsure whether mjordan meant Mechagodzilla |
| 17:56.30 | putnopvut | So I enacted the idea of having channel snapshot creation copy the formats from the channel into the snapshot instead of getting the string representations. This resulted in no performance gain. Profiling showed that instead of ast_getformatname_multiple() being a hog, it is instead ast_format_cap_copy() that is the number one caller of ao2_callback(). So I've basically replaced a six of one problem with a half dozen of an |
| 17:56.30 | putnopvut | other. |
| 17:57.01 | putnopvut | I also tried decreasing the number of buckets on the format_cap's container from 283 to 11 to see if that helped any. It did not. |
| 17:57.39 | mjordan | HM. |
| 17:57.44 | mjordan | that is unfortunate. |
| 17:57.46 | file | putnopvut, right... so store the end result on the channel itself when nativeformats is set |
| 17:58.02 | putnopvut | file: I don't understand the suggestion. |
| 17:58.33 | file | when nativeformats is set call ast_getformatname_multiple and store it on the channel, so you don't need to do anything except pass it around |
| 17:58.41 | file | nativeformats will rarely, if ever, change |
| 17:58.42 | putnopvut | Ah, I gotcha |
| 17:59.02 | putnopvut | I didn't realize that "end result" meant "string representation of formats" |
| 18:01.09 | leedm777 | hm. nativeformats_set is only called from __ast_channel_alloc_ap and ast_channel_destructor(to set it to NULL after freeing it). So where do they actually get set? |
| 18:02.43 | file | le channel drivers |
| 18:03.19 | leedm777 | crud |
| 18:13.52 | opticron | on a side note, I kind of wish the bridge snapshot provided channel name/ID pairs |
| 18:14.15 | opticron | since a lot of the externally oriented stuff still relies on channel names for user interaction |
| 18:17.35 | putnopvut | opticron: I could get behind that. |
| 18:18.43 | *** join/#asterisk-dev zigg (~matt@unaffiliated/zigg) |
| 18:22.37 | putnopvut | file: well that actually did good! Appears to be dropping CPU usage by 1-2% |
| 18:22.51 | file | not bad, not bad |
| 18:23.58 | leedm777 | file: stasis forward optimization is now merged into the group performance branch |
| 18:24.06 | file | neat |
| 18:32.31 | *** join/#asterisk-dev rzymek (~rzymek@89-75-115-17.dynamic.chello.pl) |
| 18:34.11 | rzymek | Hi, how can I call a function (CURL for example) in my module? |
| 18:38.26 | file | putnopvut, I assume that's off performance? |
| 18:39.00 | putnopvut | file: yes, team/group/performance. However, I have not done an svn update in the past hour. |
| 18:39.08 | file | ack, was just curious |
| 18:39.23 | mjordan | rzymek: ast_func_write. For an example, see app_meetme |
| 18:43.58 | rzymek | mjordan: thank you :) |
| 18:44.18 | putnopvut | file: leedm777: I've committed the native formats changes. |
| 18:44.23 | putnopvut | to group/performance |
| 18:44.34 | file | cool |
| 18:45.01 | leedm777 | yes, cool |
| 18:45.56 | file | and now the world rebuilds |
| 18:48.22 | leedm777 | putnopvut: re: your patch, how is nativeformats_str set? I'm missing it. |
| 18:48.49 | file | ditto. |
| 18:49.30 | putnopvut | Uh, could have sworn I set it in ast_channel_nativeformats_set() |
| 18:49.43 | leedm777 | that won't work, though |
| 18:49.48 | putnopvut | why not? |
| 18:49.51 | leedm777 | b/c the object is changed in the channel drivers |
| 18:50.02 | file | and thus the complicated part of the equation |
| 18:50.21 | putnopvut | what object is changed in the channel drivers? |
| 18:50.30 | putnopvut | Channel drivers can't access channel internals |
| 18:50.32 | leedm777 | ast_format_cap_add(ast_channel_nativeformats(tmp), &fmt); |
| 18:50.37 | leedm777 | ^^ crap like that |
| 18:50.39 | putnopvut | Ah, I see. |
| 19:01.40 | putnopvut | ah eff this |
| 19:01.59 | mjordan | putnopvut: is it time to pull out the dynamite? |
| 19:02.35 | putnopvut | maybe |
| 19:02.37 | file | mmm dynamite |
| 19:03.28 | leedm777 | putnopvut: next time we say "this should be easy", you should hear "IT'S A TRAP!" |
| 19:03.57 | file | leedm777, you weren't supposed to tell him that |
| 19:06.54 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.119) |
| 19:20.12 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.119) |
| 19:20.23 | *** join/#asterisk-dev datachomper (~datachomp@nat/digium/x-hvyviebnspkqxbud) |
| 19:24.15 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.119) |
| 20:16.01 | mjordan | leedm777: although I suspect this has already changed, watching a call go through app_queue while running Asterisk under gdb is ... interesting. A whole lotta stasis thread pool threads getting made. |
| 20:17.22 | rzymek | \quit |
| 20:47.51 | *** join/#asterisk-dev danjenkins (~danjenkin@cpc3-folk2-2-0-cust34.1-2.cable.virginmedia.com) |
| 20:53.16 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 20:57.32 | leedm777 | mjordan: 12, or the performance branch? |
| 21:07.24 | mjordan | 12 |
| 21:15.51 | leedm777 | that is interesting. |
| 21:16.22 | mjordan | I'd suspect it's the channel subscriptions from app_queue |
| 21:21.45 | leedm777 | it's interesting that it's creating new threads, instead of reusing from the pool |
| 21:24.33 | file | less snapshots! |
| 21:36.59 | [TK]D-Fender | more cowbell! |
| 22:00.27 | *** join/#asterisk-dev danjenkins (~danjenkin@cpc3-folk2-2-0-cust34.1-2.cable.virginmedia.com) |
| 22:06.22 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-mdcsnvqeqzsyqsrm) |
| 22:22.07 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 23:32.13 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 23:45.23 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 23:45.23 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 23:48.21 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 23:54.29 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 23:54.29 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 23:54.29 | *** join/#asterisk-dev datachomper (~datachomp@nat/digium/x-hvyviebnspkqxbud) |
| 23:54.29 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-nsztjbboncccmrmm) |
| 23:54.29 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 23:54.30 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:54.30 | *** mode/#asterisk-dev [+oooo pabelanger newtonr putnopvut snuff-work] by hitchcock.freenode.net |
| 23:54.30 | *** join/#asterisk-dev Greenlight (wluke@cpc1-dund9-0-0-cust142.16-4.cable.virginmedia.com) |
| 23:54.30 | *** join/#asterisk-dev coreyf1513 (~cfarrell@24-177-3-55.dhcp.nwtn.ct.charter.com) |
| 23:54.30 | *** join/#asterisk-dev wedhorn (~wedhorn@27-33-41-99.static.tpgi.com.au) |
| 23:54.30 | *** join/#asterisk-dev Corydon76-work (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 23:54.30 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 23:54.30 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-sfrfqwppoaqieipx) |
| 23:54.30 | *** join/#asterisk-dev jql (~awinters@74.123.82.143) |
| 23:54.30 | *** mode/#asterisk-dev [+oo Corydon76-work seanbright] by hitchcock.freenode.net |