00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:03  <trevnorris>tjfontaine: that's if you set the object property before. but if you set this.length after the allocation then execution time goes to 800ns
00:00:09  * ircretaryjoined
00:00:16  <trevnorris>so the performance drop is setting the this.parent after the sliceOnto
00:00:25  <trevnorris>well, the majority of it)
00:02:43  * Kakeraquit (Ping timeout: 252 seconds)
00:04:03  <tjfontaine>so, before attaching external memory it's pretty close, but then attach external memory and it shoots up to double the time?
00:07:02  * AlexisMocha_joined
00:07:04  * AlexisMochaquit (Ping timeout: 240 seconds)
00:08:46  <trevnorris>yup
00:09:06  <trevnorris>i'm bisecting v8 commits to figure out where it happened.
00:09:20  <trevnorris>it's like the ic goes nuts when working w/ object properties on object w/ allocated external array data
00:09:31  * AlexisMochajoined
00:09:45  <tjfontaine>what about thing with internal pointers?
00:09:51  <tjfontaine>*things
00:10:34  <trevnorris>like a v8::External ?
00:11:07  <tjfontaine>no more like a HandleWrap
00:11:20  <tjfontaine>not that they're terribly dissimilar
00:11:34  * AlexisMocha_quit (Ping timeout: 258 seconds)
00:11:42  <tjfontaine>just trying to understand the scope of things with the regression
00:12:07  <trevnorris>i'm working on that now.
00:12:16  * brsonquit (Ping timeout: 240 seconds)
00:12:17  <trevnorris>oh, and you can't set object properties on a v8::External, fwiw
00:16:40  <tjfontaine>does this appear for typed arrays as well?
00:18:45  * m76quit (Read error: Connection reset by peer)
00:19:06  * mikolalysenkojoined
00:20:23  <trevnorris>haven't checked, but I will
00:20:29  * qardjoined
00:24:11  <trevnorris>tjfontaine: it happened somewhere between v8 3.25.20 and 3.25.29. i'll continue bisecting after dinner
00:28:47  * zz_karupachanged nick to karupa
00:30:37  * dap_quit (Quit: Leaving.)
00:32:34  * sh1mmerquit (Quit: sh1mmer)
00:35:36  * sh1mmerjoined
00:37:00  * sh1mmerquit (Client Quit)
00:39:24  * sh1mmerjoined
00:42:45  * sh1mmerquit (Client Quit)
00:46:21  * quijotejoined
00:46:24  * sh1mmerjoined
00:47:33  * sh1mmerquit (Client Quit)
00:51:07  * quijotequit (Ping timeout: 252 seconds)
00:55:07  * thlorenzjoined
00:55:09  * brunklequit (Quit: brunkle)
00:56:57  * sblomquit (Read error: Connection reset by peer)
00:57:06  * sh1mmerjoined
00:58:37  * thlorenzquit (Remote host closed the connection)
01:01:35  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:02:34  * brunklejoined
01:03:06  * sh1mmerquit (Quit: sh1mmer)
01:04:56  * sh1mmerjoined
01:05:37  * tumdedumquit (Ping timeout: 258 seconds)
01:06:51  * avalanche123quit (Remote host closed the connection)
01:07:41  * tumdedumjoined
01:09:14  * qardpart
01:10:08  * calvinfoquit (Quit: Leaving.)
01:11:12  * mrvisserquit (Remote host closed the connection)
01:14:18  * sh1mmerquit (Quit: sh1mmer)
01:15:12  * sh1mmerjoined
01:18:35  * sh1mmerquit (Client Quit)
01:19:42  * sh1mmerjoined
01:21:07  * sh1mmerquit (Client Quit)
01:22:40  <trevnorris>for the record. issue happens between 3.25.27 and 3.25.28
01:24:18  * sh1mmerjoined
01:24:58  * brunklequit (Quit: brunkle)
01:25:31  * thlorenzjoined
01:27:55  * Ralithquit (Ping timeout: 276 seconds)
01:29:12  <trevnorris>getting the exact commit now
01:31:09  * calvinfojoined
01:36:37  * seldoquit (Remote host closed the connection)
01:37:59  * jmar777_joined
01:38:45  * jmar777quit (Read error: Connection reset by peer)
01:41:14  * qardjoined
01:45:55  * qardquit (Ping timeout: 265 seconds)
01:47:08  * quijotejoined
01:47:47  * mikolalysenkoquit (Ping timeout: 258 seconds)
01:51:41  * quijotequit (Ping timeout: 255 seconds)
01:57:39  * thlorenzquit (Remote host closed the connection)
02:07:01  * Ralithjoined
02:10:30  * sh1mmerquit (Quit: sh1mmer)
02:11:22  * mikolalysenkojoined
02:16:28  * inolenquit (Quit: Leaving.)
02:19:22  * rmgjoined
02:20:46  * thlorenzjoined
02:21:47  * mrvisserjoined
02:23:33  * thlorenzquit (Remote host closed the connection)
02:23:49  * rmgquit (Ping timeout: 258 seconds)
02:24:23  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:29:11  * mrvisserquit (Ping timeout: 258 seconds)
02:29:13  * sh1mmerjoined
02:41:10  * inolenjoined
02:41:59  * qardjoined
02:46:20  * qardquit (Ping timeout: 255 seconds)
02:47:55  * quijotejoined
02:52:14  * quijotequit (Ping timeout: 240 seconds)
02:53:45  * calvinfoquit (Quit: Leaving.)
02:59:26  <trevnorris>tjfontaine: freak if I know why, but here's the v8 commit that causes the perf issue: https://github.com/v8/v8/commit/a101c7c
03:03:10  <bradleymeck>trevnorris: is that the same commit --debug goes to insane slowness
03:03:26  <trevnorris>let me double check
03:04:00  <bradleymeck>also, unsure if this is the cause https://github.com/v8/v8/commit/a101c7c#diff-375e9e842263a9295cb7bb4dcb1a4a18L3683
03:05:48  * calvinfojoined
03:06:24  <trevnorris>bradleymeck: yeah, running that in debug mode is seriously borked.
03:06:48  <trevnorris>like, wtf type borked.
03:07:19  <trevnorris>it's 220x's slower
03:08:30  <trevnorris>bradleymeck: sorry, i'm missing what that section would have to do w/ the issue
03:10:47  <bradleymeck>trevnorris: checking something, I thought fixed was related to external, but I might be wrong
03:10:53  <bradleymeck>it just stuck out in my brain
03:11:48  <trevnorris>bradleymeck: well, all my tests show that if you allocate external array data on an object, then set an object property on the same one, it causes a major performance regression.
03:12:00  <trevnorris>and at this commit the issue starts to happen.
03:12:08  <trevnorris>but not sure why the two would be related.
03:12:15  <bradleymeck>so it is when you add an object property in particular?
03:15:07  <trevnorris>yeah. like in Buffer we set .length and .parent
03:15:16  <trevnorris>those cause performance to go to crap
03:15:45  <trevnorris>i verified this by allocating my own object using smalloc, which does the absolute minimum, then manually setting length.
03:16:02  <trevnorris>just setting that one object property doubled the amount of time it took to run
03:16:37  <bradleymeck>objects.cc seems a bit odd
03:16:57  <bradleymeck>has 2 cases, 1 for "legacy" 1 for new stuff related to transitionin array elements somehow
03:17:17  * sh1mmerquit (Quit: sh1mmer)
03:17:25  * emeryquit (Ping timeout: 252 seconds)
03:18:58  <bradleymeck>this makes my brain hurt
03:19:09  <bradleymeck>need to spend more time reading v8 source
03:19:42  <trevnorris>hehe, yeah.
03:20:00  <trevnorris>this is about the point where my mind just starts to wander.
03:20:12  <trevnorris>trying to understand what black magic is going on here always hurts my head.
03:21:11  <bradleymeck>I am trying to figure out what legacy means exactly
03:22:51  <trevnorris>i'm trying to revert that commit from latest 3.25. there's just one conflict in runtime.cc
03:41:08  * calvinfoquit (Quit: Leaving.)
03:41:26  <trevnorris>bradleymeck: verified. that commit introduces the majority of performance problems.
03:41:56  <trevnorris>bradleymeck: there's still some slow down, but far less that w/o that commit
03:42:45  * qardjoined
03:44:24  * sh1mmerjoined
03:45:18  <trevnorris>bradleymeck: wait, nm. ran the wrong test. ran the correct one and found that commit is 100% of the performance impact.
03:47:20  * qardquit (Ping timeout: 255 seconds)
03:48:47  * quijotejoined
03:49:37  * mikolalysenkoquit (Ping timeout: 276 seconds)
03:53:03  * quijotequit (Ping timeout: 240 seconds)
03:58:51  <trevnorris>bradleymeck: fwiw: https://github.com/joyent/node/pull/7650
04:05:02  <bradleymeck>trevnorris: I still suspec object.cc after reading the commit, but unsure since its kind of magic
04:09:50  <trevnorris>bradleymeck: feel like i'm pissing in the wind when it comes to this stuff, but it might be https://github.com/v8/v8/commit/a101c7c#diff-b2841bd3e5cfe21f81fa566002781ff3R8549
04:10:38  <trevnorris>my interpretation is that it has to rebuild the object every time the map changes. which might explain the massive amount of time IC spends in GC from the flame graphs I generated.
04:13:13  <Ralith>will uv_close block if it's passed a nullptr callback?
04:14:36  <trevnorris>Ralith: would it bock otherwise?
04:15:09  <Ralith>trevnorris: I certainly hope not
04:15:27  <Ralith>e.g. the filesystem access functions block if passed nullptr, though
04:15:30  <trevnorris>bradleymeck: that comment about legacy support you pointed out seems like it would have something to do with the problem, but i'm not smart enough to decipher that code.
04:15:59  <trevnorris>Ralith: fs and cares always "block", but they block one of the worker threads that libuv compiles with. it won't block the event loop.
04:17:31  <Ralith>trevnorris: if they're passed nullptr, they do block the event loop
04:17:39  <Ralith>I'm asking if close has the same behavior
04:17:59  * jmar777_quit (Remote host closed the connection)
04:18:31  <bradleymeck>trevnorris: that bit is around the hidden class transitions when you add/remove properties
04:18:50  <bradleymeck>I just don't understand the "legacy" bit
04:19:08  <trevnorris>Ralith: ah, wait. i'm a dork and didn't understand your question. no, it won't block afaik.
04:19:24  <bradleymeck>do you know if it hits that line?
04:19:48  <Ralith>kk, thanks
04:19:49  <bradleymeck>I think Buffers are the only ExternalArrays you should see during your test, not typed arrays?
04:20:09  <trevnorris>Ralith: don't think that's even possible since uv_close() technically doesn't finish until uv__run_closing_handles() in uv_run()
04:20:22  <Ralith>hm?
04:20:41  * rmgjoined
04:20:49  <trevnorris>Ralith: the callback you pass to uv_close() isn't called until a different phase of the uv_run() loop. namely, uv__run_closing_handles()
04:21:03  <Ralith>ah
04:21:50  <trevnorris>bradleymeck: good point. have an idea how I could trace that?
04:22:00  <bradleymeck>gdb?
04:24:19  <trevnorris>bradleymeck: yeah... guess I could try that. I've just never tried to debug v8 internals before.
04:25:17  <trevnorris>oy, this hurts my brain. i'll continue looking at it tomorrow.
04:25:20  * rmgquit (Ping timeout: 255 seconds)
04:25:21  * trevnorris&
04:25:21  <LOUDBOT>I JUST WANNA HAVE SOME SEX
04:26:43  <bradleymeck>...
04:26:46  <bradleymeck>wow
04:39:29  * brunklejoined
04:43:32  * qardjoined
04:45:22  * qard1joined
04:47:50  * qardquit (Ping timeout: 255 seconds)
04:49:29  * quijotejoined
04:49:31  * qard1quit (Ping timeout: 240 seconds)
04:54:05  * quijotequit (Ping timeout: 258 seconds)
04:55:13  * mikolalysenkojoined
04:59:44  * mikolalysenkoquit (Ping timeout: 265 seconds)
05:12:46  * mikealquit (Quit: Leaving.)
05:13:32  * calvinfojoined
05:14:29  * m76joined
05:33:13  * AlexisMocha_joined
05:33:27  * AlexisMochaquit (Ping timeout: 240 seconds)
05:43:02  * c4miloquit (Remote host closed the connection)
05:43:19  * avalanche123joined
05:44:04  * mikealjoined
05:46:07  * qardjoined
05:47:47  * petka_joined
05:48:15  * mikealquit (Ping timeout: 240 seconds)
05:50:00  * qardquit (Read error: Connection reset by peer)
05:50:06  * qardjoined
05:50:13  * quijotejoined
05:50:19  * qardquit (Client Quit)
05:52:17  * mikealjoined
05:54:38  * quijotequit (Ping timeout: 240 seconds)
05:57:38  * bajtosjoined
06:06:13  * brunklequit (Quit: brunkle)
06:09:05  * vtjnashquit (Remote host closed the connection)
06:09:37  * vtjnashjoined
06:12:20  * brunklejoined
06:12:37  * avalanche123quit (Remote host closed the connection)
06:13:51  * vtjnashquit (Ping timeout: 240 seconds)
06:15:59  * AlexisMocha_quit (Ping timeout: 252 seconds)
06:17:56  * avalanche123joined
06:20:48  * AlexisMochajoined
06:38:04  * bajtosquit (Quit: bajtos)
06:44:20  * rendarjoined
06:50:46  * avalanche123quit (Remote host closed the connection)
06:51:08  * quijotejoined
06:51:14  * avalanche123joined
06:51:28  * bajtosjoined
06:52:12  * janjongboomjoined
06:55:34  * avalanche123quit (Ping timeout: 240 seconds)
06:56:10  * quijotequit (Ping timeout: 276 seconds)
07:08:36  * AlexisMocha_joined
07:08:56  * AlexisMochaquit (Ping timeout: 255 seconds)
07:22:50  * rmgjoined
07:23:01  * indexzerojoined
07:30:51  * saapazjoined
07:32:08  * AlexisMochajoined
07:32:43  * AlexisMocha_quit (Ping timeout: 240 seconds)
07:32:47  * Ralith_joined
07:37:41  * rmgquit (*.net *.split)
07:37:41  * bajtosquit (*.net *.split)
07:37:41  * Ralithquit (*.net *.split)
07:37:41  * shrubberyquit (*.net *.split)
07:37:41  * AvianFluquit (*.net *.split)
07:39:14  * AvianFlujoined
07:48:15  * wolfeidauquit (Remote host closed the connection)
07:51:45  * calvinfoquit (Quit: Leaving.)
07:51:46  * quijotejoined
07:56:14  * quijotequit (Ping timeout: 240 seconds)
08:01:57  * roxluquit (Ping timeout: 265 seconds)
08:06:20  * brunklequit (Quit: brunkle)
08:13:31  * brunklejoined
08:15:22  * brunklequit (Client Quit)
08:19:43  * WalrusPony1joined
08:21:54  * WalrusPonyquit (Ping timeout: 240 seconds)
08:24:57  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:33:15  * wolfeidaujoined
08:52:31  * quijotejoined
08:55:52  * AlexisMocha_joined
08:56:21  * AlexisMochaquit (Ping timeout: 258 seconds)
08:56:57  * quijotequit (Ping timeout: 252 seconds)
08:57:21  * janjongboomjoined
09:06:34  * wolfeida_joined
09:08:38  * wolfeidauquit (Ping timeout: 255 seconds)
09:20:01  * AlexisMochajoined
09:21:53  * indexzeroquit (Ping timeout: 252 seconds)
09:21:58  * AlexisMocha_quit (Ping timeout: 240 seconds)
09:23:27  * indexzerojoined
09:23:29  * AlexisMocha_joined
09:24:14  * AlexisMochaquit (Ping timeout: 240 seconds)
09:26:52  * AlexisMochajoined
09:28:16  * AlexisMocha_quit (Ping timeout: 276 seconds)
09:45:58  * janjongboomquit (Ping timeout: 240 seconds)
09:46:54  * janjongboomjoined
09:53:18  * quijotejoined
09:57:57  * quijotequit (Ping timeout: 265 seconds)
10:11:00  * hzjoined
10:12:29  * hzquit (Client Quit)
10:27:09  * mrvisserjoined
10:30:49  * Kakerajoined
10:53:40  * m76quit (Read error: Connection reset by peer)
10:54:15  * quijotejoined
10:58:19  * quijotequit (Ping timeout: 240 seconds)
11:05:25  * AlexisMocha_joined
11:06:43  * AlexisMochaquit (Ping timeout: 240 seconds)
11:20:12  * indexzeroquit (Quit: indexzero)
11:29:31  * janjongboomquit (Ping timeout: 240 seconds)
11:30:28  * janjongboomjoined
11:39:30  * AlexisMochajoined
11:39:53  * AlexisMocha_quit (Ping timeout: 264 seconds)
11:42:20  * bradleymeckquit (Quit: bradleymeck)
11:46:33  * janjongboomquit (Ping timeout: 258 seconds)
11:47:30  * janjongboomjoined
12:09:26  * AlexisMocha_joined
12:09:44  * AlexisMochaquit (Ping timeout: 255 seconds)
12:15:55  * janjongboomquit (Ping timeout: 240 seconds)
12:17:01  * janjongboomjoined
12:24:28  * AlexisMochajoined
12:25:35  * AlexisMocha_quit (Ping timeout: 252 seconds)
12:28:26  * Kakeraquit (Ping timeout: 255 seconds)
12:32:29  * Kakerajoined
12:43:31  * mrvisserquit (Remote host closed the connection)
12:46:06  * m76joined
12:50:14  * mrvisserjoined
12:52:10  * AlexisMocha_joined
12:52:15  * AlexisMochaquit (Ping timeout: 240 seconds)
12:55:36  * quijotejoined
12:59:25  * wolfeida_quit (Remote host closed the connection)
13:00:03  * quijotequit (Ping timeout: 252 seconds)
13:02:54  * bradleymeckjoined
13:02:55  * vtjnashjoined
13:11:38  * thlorenzjoined
13:11:58  * AlexisMocha_quit (Ping timeout: 240 seconds)
13:12:12  * AlexisMochajoined
13:15:15  * SMD1joined
13:22:49  <SMD1>Hey there.
13:22:49  <SMD1>Seems like I need some help understanding how to handle with libuv.
13:22:49  <SMD1>So I'm writing an userspace library for a device driver.
13:22:49  <SMD1>Firstly I used uv_fs_read/uv_fs_write to read/write data to the device, but it was rather slow: I was told to try to use pipes.
13:22:49  <SMD1>I tried that one but faced the problem: if I run uv_loop with UV_RUN_DEFAULT option, it endlessly writes data to device file. Another problem is that despite the loop doesn't run yet, data has already been written once.
13:22:50  <SMD1>I used pipe code from this article: http://nikhilm.github.io/uvbook/filesystem.html#buffers-and-streams
13:23:02  <bradleymeck>gah
13:24:53  <bradleymeck>SMD1: define “data has been written once”. also it should write as long as the source pipe is not closed
13:25:18  * AlexisMocha_joined
13:26:14  * AlexisMochaquit (Ping timeout: 240 seconds)
13:29:53  <SMD1>bradleymeck: I mean calling uv_write(pipe) causes writing to file even before run_loop(). And after calling run_loop() it writes again.
13:39:38  * m76quit (Ping timeout: 258 seconds)
13:41:02  * AlexisMochajoined
13:41:33  * AlexisMocha_quit (Ping timeout: 258 seconds)
13:46:58  * AlexisMochaquit (Ping timeout: 240 seconds)
13:47:28  * AlexisMochajoined
13:54:07  * wolfeidaujoined
13:55:47  * jmar777joined
13:56:16  * quijotejoined
13:59:11  * AlexisMocha_joined
13:59:34  * AlexisMochaquit (Ping timeout: 258 seconds)
14:00:53  * quijotequit (Ping timeout: 255 seconds)
14:06:10  * vtjnashquit (Remote host closed the connection)
14:07:35  * c4milojoined
14:32:12  <bradleymeck>https://code.google.com/p/v8/issues/detail?id=3337 for great justice
14:32:16  <bradleymeck><3 trevnorris
14:32:32  * janjongboomquit (Ping timeout: 258 seconds)
14:33:35  * janjongboomjoined
14:45:16  * m76joined
14:51:51  * AlexisMochajoined
14:53:54  * AlexisMocha_quit (Ping timeout: 276 seconds)
14:57:09  * quijotejoined
15:01:55  * janjongboomquit (Ping timeout: 240 seconds)
15:01:58  * quijotequit (Ping timeout: 265 seconds)
15:03:06  * janjongboomjoined
15:04:10  * AlexisMocha_joined
15:04:46  * c4miloquit (Remote host closed the connection)
15:05:31  * janjongboomquit (Client Quit)
15:06:08  * AlexisMochaquit (Ping timeout: 255 seconds)
15:06:22  * janjongboomjoined
15:06:57  * mikealquit (Quit: Leaving.)
15:08:00  * rmgjoined
15:08:54  * mikealjoined
15:09:43  * AlexisMochajoined
15:10:13  * AlexisMocha_quit (Ping timeout: 252 seconds)
15:10:18  * bradleymeckquit (Quit: bradleymeck)
15:13:46  * rmgquit (Remote host closed the connection)
15:14:18  * rmgjoined
15:18:39  * rmgquit (Ping timeout: 240 seconds)
15:20:04  * c4milojoined
15:21:23  * bradleymeckjoined
15:25:03  * bradleymeckquit (Client Quit)
15:25:06  * mrvisserquit (Remote host closed the connection)
15:25:32  * thlorenzquit (Remote host closed the connection)
15:26:08  * thlorenzjoined
15:30:26  * thlorenzquit (Ping timeout: 255 seconds)
15:31:57  * bradleymeckjoined
15:36:07  <MI6>joyent/libuv: Rasmus Christian Pedersen master * 70c4256 : unix, windows: getnameinfo implementation - http://git.io/Qu6NAA
15:51:07  * c4miloquit (Ping timeout: 240 seconds)
15:53:17  * c4milojoined
15:58:09  * quijotejoined
16:02:37  * quijotequit (Ping timeout: 258 seconds)
16:05:25  * mikealquit (Quit: Leaving.)
16:07:16  * mikealjoined
16:13:27  * SMD1part
16:16:44  * rmgjoined
16:18:42  * dap_joined
16:18:56  * TooTallNatejoined
16:31:38  * janjongboomquit (Ping timeout: 255 seconds)
16:32:26  * janjongboomjoined
16:33:40  * mrvisserjoined
16:36:25  * AlexisMocha_joined
16:37:51  * AlexisMochaquit (Ping timeout: 240 seconds)
16:41:01  * rosskjoined
16:43:06  * brunklejoined
16:44:35  * roxlujoined
16:44:58  <roxlu>hey
16:47:05  <roxlu>I've creaetd a simple UDP server/client and I'm sending with uv_udp_send using an uv_ip4_addr initialize with "0.0.0.0" and some port. I'm a complete newb with udp, but I should be able to receive data on another pc/ip right?
16:47:19  * sblomjoined
16:47:26  <roxlu>e.g. when I read packets from the IP of the 'sender' ?
16:50:40  * AlexisMochajoined
16:52:08  <roxlu>Hmm looks like VLC has problems with this ...
16:52:13  * roxluneeds to look into this
16:52:26  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:52:31  * AlexisMocha_quit (Ping timeout: 252 seconds)
16:54:00  * AlexisMocha_joined
16:55:27  * AlexisMochaquit (Ping timeout: 276 seconds)
16:56:41  * Ralith_quit (Ping timeout: 264 seconds)
16:57:42  * calvinfojoined
16:58:39  * quijotejoined
16:58:48  * dap_1joined
17:01:39  * dap_quit (Ping timeout: 258 seconds)
17:02:55  * mikealquit (Quit: Leaving.)
17:03:09  * mikealjoined
17:03:09  * quijotequit (Ping timeout: 252 seconds)
17:07:03  * janjongboomjoined
17:07:43  * AlexisMochajoined
17:07:54  * AlexisMocha_quit (Ping timeout: 240 seconds)
17:16:35  * dap_1quit (Quit: Leaving.)
17:19:26  * brsonjoined
17:20:20  * sh1mmerquit (Quit: sh1mmer)
17:25:48  * dap_joined
17:26:29  * bradleymeckquit (Quit: bradleymeck)
17:30:55  * seldojoined
17:31:30  * AlexisMocha_joined
17:31:44  * AlexisMochaquit (Ping timeout: 255 seconds)
17:33:52  * avalanche123joined
17:34:06  * sh1mmerjoined
17:34:16  <indutny>hey
17:34:38  * AlexisMochajoined
17:35:38  * AlexisMocha_quit (Ping timeout: 240 seconds)
17:36:09  <tjfontaine>hey
17:36:09  * brsonquit (Ping timeout: 252 seconds)
17:36:44  * brsonjoined
17:45:30  * kenperkinsquit (Ping timeout: 276 seconds)
17:47:33  * euoiajoined
17:47:34  * euoiaquit (Client Quit)
17:48:51  <indutny>tjfontaine: how are you?
17:56:16  * bradleymeckjoined
17:59:37  * quijotejoined
18:04:29  * quijotequit (Ping timeout: 264 seconds)
18:12:41  * sh1mmerquit (Quit: sh1mmer)
18:15:18  <trevnorris>bradleymeck: heh, thanks. it was mraleph that determined the issue. I just bisected the commits.
18:15:41  <tjfontaine>does the same thing happen with internal fields?
18:15:47  <tjfontaine>indutny: I'm ok -- you?
18:16:18  * sh1mmerjoined
18:17:44  <trevnorris>tjfontaine: the issue only happens if you run SetIndexedPropertiesToExternalArrayData() on the object.
18:18:33  <bradleymeck>so it is just the indexed property interceptors?
18:19:16  <bradleymeck>i guess these aren’t interceptors really
18:19:25  <tjfontaine>have you looked at implementing Buffer in terms of internal fields and a getter/setter pattern? I'm just curious if and how much overhead that adds
18:19:48  <bradleymeck>field access is slower
18:19:59  <trevnorris>it's that each object generates a new map, so it can never get optimized
18:20:21  <trevnorris>tjfontaine: you can't set a generic getter/setter for all numeric fields
18:20:30  <bradleymeck>someone got it assigned as soon as the issue appeared pretty much
18:20:31  <trevnorris>i've actually wondered about using this as well
18:20:37  <bradleymeck>trevnorris: you can, /digs
18:20:49  <tjfontaine>bradleymeck: internal field access or the the getter/setter portion -- I have no problem believing its slower I'm just curious to see the quantification and the stacks
18:22:10  <bradleymeck>SetIndexedPropertyHandler can be used to override indexed (numeric) field access, and then you can manually grab the values off of internal fields, but that requires getting out of the vm optimizer
18:22:19  <bradleymeck>https://code.google.com/p/v8/source/browse/trunk/include/v8.h#3613
18:22:38  <bradleymeck>tjfontaine: it is mostly the getter/setter that is the slow bit
18:23:20  <trevnorris>bradleymeck: ah, though it must be set on an ObjectTemplate. Buffer is only created in JS land.
18:24:09  <bradleymeck>can we not export the object constructor function to JS?
18:24:36  <trevnorris>i have no idea how you'd do that
18:25:49  <tjfontaine>consturctor_template->GetFunction() and use that as the return value from setupBufferJS?
18:25:57  <tjfontaine>it's all kinda crazy
18:26:06  <bradleymeck>avoid interceptors if you can
18:26:17  <trevnorris>hm.... tjfontaine that's an interesting idea.
18:26:30  <bradleymeck>externalarray was soo much faster last I checked (granted that is about 1.5 years ago XD)
18:27:05  <trevnorris>it's still pretty freakin fast.
18:27:41  <bradleymeck>profiling time?
18:27:46  <trevnorris>and now that they require you to use a weak persistent handle on any array buffer's where you pass memory means that all performance awesomeness is down the drain.
18:28:31  <trevnorris>bradleymeck: on which part? calling SetIndexedPropertiesToExternalArrayData?
18:29:03  <bradleymeck>yes, externalarrays were much faster than custom interceptors since hydrogen optimized them
18:29:46  <bradleymeck>but if thats not the case now, idk
18:29:57  <trevnorris>accessing memory via array indexes on an object w/ external array data is so fast i can't properly profile it.
18:30:06  <trevnorris>it's sub nanosecond
18:36:46  * quijotejoined
18:38:33  * stephankquit (Quit: *Poof!*)
18:39:13  <tjfontaine>trevnorris: so it doesn't matter if these properties exist before we attach the data?
18:40:26  * rendarquit (Ping timeout: 265 seconds)
18:43:11  <trevnorris>tjfontaine: possibly, but the reproductions are greater than that. every object will have a new map, so any function that accepts a Buffer won't ever optimize because the map check will always fail.
18:44:04  <trevnorris>*repercussions
18:45:05  <trevnorris>but in terms of raw performance, yeah. it doesn't help we have to set .parent after the fact
18:45:20  <tjfontaine>trevnorris: so to clarify, regardless if we mutate the map, setexternal always creates a new one?
18:45:32  <trevnorris>yup. that's the bug.
18:45:39  <tjfontaine>ok
18:46:50  * seldoquit (Remote host closed the connection)
18:47:41  * brsonquit (Ping timeout: 264 seconds)
18:48:17  * seldojoined
18:52:09  * avalanche123quit (Remote host closed the connection)
18:56:13  * avalanche123joined
18:59:02  * thlorenzjoined
19:05:23  * Ralithjoined
19:08:29  * brunklequit (Quit: brunkle)
19:09:49  * brunklejoined
19:10:24  * seldoquit (Remote host closed the connection)
19:11:03  * seldojoined
19:12:25  * seldo_joined
19:12:30  * seldoquit (Remote host closed the connection)
19:15:14  * stephankjoined
19:15:39  * mikolalysenkojoined
19:25:34  <indutny>tjfontaine: great
19:26:17  * groundwater_quit (Read error: Connection reset by peer)
19:26:39  * groundwater_joined
19:27:37  * quijotequit (Ping timeout: 252 seconds)
19:34:40  * brunklequit (Quit: brunkle)
19:37:24  <trevnorris>tjfontaine: until the issue is resolved what do you think about either this pr: https://github.com/joyent/node/pull/7650#issuecomment-43613899
19:37:37  <trevnorris>tjfontaine: or reverting back to 3.25.27?
19:38:21  * c4miloquit (Remote host closed the connection)
19:41:28  <tjfontaine>trevnorris: I'm basically fine with reverting that patch, but I'd like to get some more guidance from upstream -- that is to say if they submit a patch that sovles it I'd like to see if we can get them to backport to 3.25
19:42:01  <tjfontaine>trevnorris: I'd like to see someone with an app and performance numbers to see what this means in real world though
19:45:24  * c4milojoined
19:46:20  * rmgquit (Remote host closed the connection)
19:46:54  * rmgjoined
19:46:57  * AlexisMocha_joined
19:48:34  * AlexisMochaquit (Ping timeout: 240 seconds)
19:50:07  * dshaw_joined
19:51:29  * rmgquit (Ping timeout: 265 seconds)
19:52:50  <tjfontaine>we should see this somewhat in latency, but also in throughput
19:53:27  <trevnorris>also in memory usage
19:53:35  <tjfontaine>we're talking about a doubling of the time, ~400ns to ~800ns -- if this is in the realm of hurting real world performance we should see it
19:53:41  <tjfontaine>sure, and more pressure means more gc runs
19:53:45  <tjfontaine>which normally would affect latency
19:54:36  * avalanche123quit (Remote host closed the connection)
19:54:43  <tjfontaine>it's not that we can't float a patch/reversion it's just a significant risk to our ability to maintain and upgrade
19:55:30  <tjfontaine>so the benefit to us not being on the golden path needs to be 100% clear
19:56:27  * avalanche123joined
19:59:19  * jmar777quit (Remote host closed the connection)
20:01:25  * sh1mmerquit (Quit: sh1mmer)
20:02:28  * dshaw_quit (Quit: Leaving.)
20:04:27  * sh1mmerjoined
20:04:30  * rmgjoined
20:04:55  * AlexisMochajoined
20:05:23  * AlexisMocha_quit (Ping timeout: 255 seconds)
20:09:16  * AlexisMocha_joined
20:09:31  <bradleymeck>tjfontaine: perhaps including this on the issue would be a good idea?https://code.google.com/p/v8/issues/detail?id=3337
20:09:48  * AlexisMochaquit (Ping timeout: 276 seconds)
20:09:56  <trevnorris>tjfontaine: instantiation time is from 250ns to 1500ns
20:11:13  <tjfontaine>bradleymeck: ya, the more data we bring to the table the happier everyone gets
20:11:50  <tjfontaine>trevnorris: sure, in any event we just want to show precisely why we have to make the change, but just beyond a micro benchmark
20:14:21  <tjfontaine>it's just a marker that we can look back on, and confirm our decisions at another point after other v8 changes are made
20:14:29  <trevnorris>ok. i'll come up with as close to a "real world" example as possible later.
20:15:01  <trevnorris>possibly, just piping data. that would be a quick one. let me check
20:25:44  * quijotejoined
20:29:20  <trevnorris>tjfontaine: quick run of benchmark/net/net-pipe.js: pre patch:
20:29:21  <trevnorris>net/net-pipe.js len=102400 type=buf dur=5: 18.075
20:29:35  * brunklejoined
20:29:36  <trevnorris>post patch: net/net-pipe.js len=102400 type=buf dur=5: 19.975
20:30:36  * quijotequit (Ping timeout: 276 seconds)
20:31:29  <trevnorris>tjfontaine: so the benchmark shows about a 10% loss.
20:31:47  * brsonjoined
20:32:15  * stephankquit (Ping timeout: 240 seconds)
20:33:09  * avalanche123quit (Remote host closed the connection)
20:33:33  * WalrusPony1changed nick to CPlusPlusPony
20:34:50  * stephankjoined
20:35:45  <trevnorris>tjfontaine: tls/throughput.js dur=5 type=buf size=1024 has a 20% performance decrease
20:38:39  * mikolalysenkoquit (Ping timeout: 240 seconds)
20:38:46  * avalanche123joined
20:40:16  <trevnorris>tjfontaine: but all of those create buffers from c++, which bypasses the issue of needing to set .parent. i can't think of a good library to benchmark that would just call new Buffer() a lot.
20:42:01  * brunklequit (Quit: brunkle)
20:47:32  * mrvisserquit (Remote host closed the connection)
20:54:41  <tjfontaine>any one doing protocol parsing and writing in js
20:54:54  <tjfontaine>not that I have good benchmarks for it, but my dns library woudl
20:54:55  <tjfontaine>*would
20:54:58  <bradleymeck>msgpack perhaps?
20:55:09  <tjfontaine>the mysql and pgsql and redis drivers probably
20:55:17  <tjfontaine>the ones using pure js
20:56:43  * AlexisMochajoined
20:57:54  * AlexisMocha_quit (Ping timeout: 276 seconds)
21:00:32  <trevnorris>ah, good pintj
21:00:36  <trevnorris>point
21:03:43  <bradleymeck>seems like most end up using https://www.npmjs.org/package/bops
21:04:39  <bradleymeck>bufferops, binary ops, soo many libs on npm
21:10:49  * rmgquit (Remote host closed the connection)
21:11:01  * bradleymeck_joined
21:12:12  * parshap_quit (Ping timeout: 265 seconds)
21:13:48  * parshap_joined
21:15:20  * roxluquit (Quit: Lost terminal)
21:18:12  * dshaw_joined
21:18:18  * indexzerojoined
21:18:58  * AlexisMochaquit (Ping timeout: 265 seconds)
21:23:28  * rendarjoined
21:26:26  * quijotejoined
21:28:04  * avalanche123quit (Remote host closed the connection)
21:31:02  * avalanche123joined
21:31:02  * avalanche123quit (Remote host closed the connection)
21:31:08  * AlexisMochajoined
21:31:14  * avalanche123joined
21:31:29  * quijotequit (Ping timeout: 264 seconds)
21:32:02  * jmar777joined
21:32:28  * bradleymeckquit (Quit: bradleymeck)
21:32:28  * bradleymeck_changed nick to bradleymeck
21:37:06  * quijotejoined
21:38:08  * rendarquit
21:41:41  * quijotequit (Ping timeout: 264 seconds)
21:45:07  * AlexisMochaquit (Ping timeout: 240 seconds)
21:45:25  * AlexisMochajoined
21:45:38  * rmgjoined
21:47:48  * brunklejoined
21:58:25  * thlorenzquit (Remote host closed the connection)
21:58:47  * mrvisserjoined
21:59:00  * bradleymeckquit (Quit: bradleymeck)
22:00:01  * AvianFluquit (Remote host closed the connection)
22:01:03  * bradleymeckjoined
22:02:23  * ryancolejoined
22:02:56  * dshaw_quit (Quit: Leaving.)
22:06:01  * mrvisserquit (Ping timeout: 258 seconds)
22:20:33  * indexzeroquit (Quit: indexzero)
22:20:48  * AlexisMocha_joined
22:20:50  * ryancolequit
22:21:48  * AlexisMochaquit (Ping timeout: 265 seconds)
22:23:30  * AlexisMochajoined
22:24:38  * brson_joined
22:25:05  * AlexisMocha_quit (Ping timeout: 252 seconds)
22:25:08  * brsonquit (Ping timeout: 255 seconds)
22:30:20  * stephankquit (Quit: *Poof!*)
22:31:12  * AlexisMocha_joined
22:31:42  * AlexisMochaquit (Ping timeout: 258 seconds)
22:35:21  * AlexisMocha_quit (Ping timeout: 252 seconds)
22:35:35  * AlexisMochajoined
22:37:52  * quijotejoined
22:42:26  * quijotequit (Ping timeout: 258 seconds)
22:46:07  * m76quit (Read error: Connection reset by peer)
22:52:10  * bradleymeckwishes modules did not use process.x so much
22:53:42  * tjfontainewishes we didn't hang everythign off process
22:53:53  <tjfontaine>process.hrtime instead of timers.hrtime
22:53:56  <tjfontaine>q e d
23:01:39  * wolfeidauquit
23:01:56  * bradleymeckquit (Quit: bradleymeck)
23:07:08  * dshaw_joined
23:07:24  * calvinfoquit (Quit: Leaving.)
23:15:49  * thlorenzjoined
23:27:55  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:27:58  * Kakeraquit (Ping timeout: 240 seconds)
23:28:49  * thlorenzquit (Remote host closed the connection)
23:35:47  * thlorenzjoined
23:38:36  * quijotejoined
23:39:10  * wolfeidaujoined
23:43:11  * quijotequit (Ping timeout: 255 seconds)
23:46:14  * petka_quit (Quit: Connection closed for inactivity)
23:46:54  * mrvisserjoined
23:46:58  * brunklequit (Quit: brunkle)
23:47:21  * brson_quit (Ping timeout: 265 seconds)
23:49:54  * brsonjoined
23:51:51  * c4miloquit (Remote host closed the connection)
23:52:39  * thlorenzquit (Remote host closed the connection)
23:53:13  * thlorenzjoined
23:53:55  * brunklejoined
23:54:27  * dshaw_quit (Read error: Connection reset by peer)
23:57:35  * thlorenzquit (Ping timeout: 255 seconds)
23:58:33  * thlorenzjoined