00:02:09  <caitp>doing stuff in c++ isn't necessarily bad
00:03:41  <caitp>there are costs to jumping between js and c++, but it doesn't always mean slower
00:04:55  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
00:07:16  <xaxxon>caitp: I made bad decisions. tight loops going back and forth. I've mitigated a lot of it via caching results... but was hoping for a miracle :)
00:08:23  <xaxxon>caitp: I asked this long ago and got a very strong non-answer, but do you have any information on what has an increased cost when you change an object's prototype after creation? I see lots of scary generic warnings, but no specifics on even things to look out for
00:09:39  <xaxxon>I create an c++-defined object type but then set the prototype to a javascript-created object -- and there's no C++ api call for doing that in a single step that I know of. I was told to "benchmark it" but i'm not really in a situation where I can benchmark an apples to apples comparison
00:10:02  <caitp>xaxxon: v8 tries to keep prototype objects in fast mode, which greatly simplifies lookup
00:10:33  <xaxxon>makes sense
00:11:11  <caitp>modifying can break fast mode, but it is possible to force it to be fast again
00:11:22  <caitp>sort of a silly hack
00:11:29  <xaxxon>I'm down with silly
00:11:52  * Guest59joined
00:12:05  <xaxxon>it's a one-time thing I do immediately at object creation time and I dont create a lot of these types of objects, but they live a long time and get used a lot, so it would be useful
00:12:29  <xaxxon>and that' definitely something I could benchmark to see the difference
00:14:15  <xaxxon>you're such a tease!
00:14:55  <xaxxon>maybe this: http://stackoverflow.com/questions/24987896/how-does-bluebirds-util-tofastproperties-function-make-an-objects-properties
00:16:45  <caitp>https://github.com/v8/v8/blob/master/test/mjsunit/fast-prototype.js
00:16:47  <caitp>various tricks in there, with some documentation
00:17:13  <xaxxon>I'l check it out. thanks!
00:17:41  <xaxxon>https://jsperf.com/test-dictionary-mode
00:32:27  * bradleymeckjoined
01:24:35  * bradleymeckquit (Quit: bradleymeck)
01:53:18  * xaxxonquit (Ping timeout: 246 seconds)
01:59:39  * xaxxonjoined
02:40:14  * bradleymeckjoined
02:41:36  <xaxxon>oooh, sneaky. I was getting an object being destroyed weak ref callback when I really didn't expect it.. turned out I was assigning it to something I had an accessor for.. so I guess the assignment was just getting silently dropped on the floor and the object available for GC. Any way to detect this at runtime?
02:43:06  <xaxxon>hrmm I think it's more complicated than that.
02:43:51  <xaxxon>also if it's not I know the answer.
03:26:17  * plutoniixjoined
03:50:17  * bradleymeckquit (Quit: bradleymeck)
04:05:17  * Ultrasaucejoined
04:19:23  * Ultrasaucequit (Read error: Connection reset by peer)
04:26:10  * BobGneujoined
07:46:42  * xaxxonquit (Quit: Leaving)
08:56:55  * Guest59quit (Ping timeout: 244 seconds)
08:57:29  * Guest59joined
09:39:08  * plutoniixquit (Ping timeout: 250 seconds)
10:18:48  * hferreiro_joined
10:19:09  * Vbitzquit (Ping timeout: 258 seconds)
10:19:18  * hferreiroquit (Ping timeout: 258 seconds)
10:19:19  * sxaquit (Ping timeout: 258 seconds)
10:19:20  * mikolalysenkoquit (Ping timeout: 258 seconds)
10:19:21  * hferreiro_changed nick to hferreiro
10:19:22  * luitequit (Ping timeout: 258 seconds)
10:23:46  * mikolalysenkojoined
10:24:08  * Vbitzjoined
10:24:10  * plutoniixjoined
10:24:55  * APKjoined
10:25:44  * oleavrquit (Ping timeout: 258 seconds)
10:25:44  * aperezdcquit (Ping timeout: 258 seconds)
10:25:44  * AKPWDquit (Ping timeout: 258 seconds)
10:26:48  * luitejoined
10:27:42  * oleavrjoined
10:31:51  * aperezdcjoined
10:31:58  * sxajoined
10:44:12  * plutoniixquit (Quit: Leaving)
11:00:08  * bradleymeckjoined
11:17:48  * kenansulaymanjoined
11:49:13  * BobGneuquit (Read error: Connection reset by peer)
12:51:46  * ncthom91joined
13:19:47  * bradleymeckquit (Quit: bradleymeck)
13:20:52  <caitp>xaxxon: sorry, what do you mean "accessor" --- like an API defined accessor, or JS defined? and, by "dropped on the floor", are you saying the accessor isn't retaining the target object, or the accessor call is getting elided from optimized code, or what?
13:33:22  * ncthom91quit (Quit: Textual IRC Client: www.textualapp.com)
14:18:08  * Guest59quit (Ping timeout: 260 seconds)
15:19:06  * APKchanged nick to AKPWD
15:19:24  * seventhjoined
15:23:45  * bradleymeckjoined
15:26:22  * bradleymeckquit (Client Quit)
15:30:30  * hferreiroquit (Quit: Connection closed for inactivity)
16:08:57  * bradleymeckjoined
16:11:10  * bradleymeckquit (Client Quit)
16:22:55  * mounibecjoined
16:23:30  * RT|Chatzillaquit (Quit: ChatZilla [Firefox])
16:26:39  * rwlbuisjoined
16:28:09  * sxaquit (Read error: Connection reset by peer)
16:33:39  * sxajoined
16:47:56  * seventhquit (Ping timeout: 260 seconds)
16:59:04  * seventhjoined
17:09:34  * bradleymeckjoined
17:10:05  * bradleymeckquit (Client Quit)
17:15:24  * mounibecquit (Quit: My Mac has gone to sleep. ZZZzzz…)
17:20:08  * bradleymeckjoined
17:25:08  * bradleymeckquit (Quit: bradleymeck)
17:40:04  * bradleymeckjoined
17:40:47  * bradleymeckquit (Client Quit)
17:44:58  * bradleymeckjoined
17:46:13  * bradleymeckquit (Client Quit)
17:56:16  <gsathya>caitp: heh, we have tests that check the observable optimization of the builtin promises fastpath in ResolvePromise
17:56:34  <gsathya>caitp: mjsunit/harmony/async-await-no-constructor and mjsunit/harmony/mirror-async-function-promise; both fail without the fast path
17:58:09  <caitp>well, the async-await-no-constructor test clearly isn't valid per spec
17:58:46  <gsathya>yeah
17:58:48  <caitp>where does the mirror test fail?
17:59:11  <gsathya>var rejectedv = (async function() { return Promise.reject("reject"); })(); needs a %RunMicrotasks()
17:59:20  <gsathya>because it takes two ticks now
17:59:49  <caitp>ah I see
17:59:59  <caitp>I thought all the assertions were happening after the %RunMicrotasks() at the end
18:00:36  <caitp>JSC had this same bug, I already landed the fix over there
18:00:59  <caitp>but, if you guys think a spec change is possible, maybe we should hold off on fixing it
18:03:44  <gsathya>i remember asking domenic about this, but i forgot the reason he mentioned; will talk to him this week about this
18:04:16  <caitp>well, Promise.resolve() has this short circuiting behaviour in the spec, but it's not restricted to just builtin promises
18:04:43  <caitp>but we can't do the same kind of trick that the Promise.resolve shortcut does for async functions
18:05:52  <caitp>unless you assume the promise constructor for async functions is always %Promise%, which I guess is true
18:11:39  * bradleymeckjoined
18:16:34  * bradleymeckquit (Quit: bradleymeck)
19:00:03  * Net147quit (Ping timeout: 245 seconds)
19:01:31  * Net147joined
20:05:05  * mounibecjoined
20:37:31  * seventhquit (Quit: ...)
21:02:41  <caitp>littledan__ : well, there's 3 possibilities: either we drop the invalid optimization and find a more valid way (my preference), we change the spec to treat Arrays specially and not call the iterator at all (probably not possible anymore without breaking some content), or we keep having a non-interoperable implementation to take a shortcut that we can beat anyways
21:13:01  <littledan__>caitp: What if we leave it as the status quo for now, while we're investigating the performance overhead and options? I doubt we'll get the spec text change. Are you totally convinced there's no way to do the optimization?
21:13:18  <littledan__>for the Promise stuff, I think there is a chance we'll get a spec text change, OTOH
21:13:38  <caitp>I don't think it's worth even trying to do the invalid optimizations, that's effort better spent on just making the spec'd behaviour fast
21:17:35  * Guest59joined
21:22:15  * Guest59quit (Ping timeout: 260 seconds)
21:26:09  <caitp>re: typed arrays
21:26:18  <caitp>but if it's observable, I think it's a bad idea
21:29:10  <littledan__>well, the prior state was to leave the optimization in. Why not just stick with that while we're investigating?
21:29:37  <littledan__>it's true it's observable and does not meet the spec, but the slowdown was really huge previously
21:30:07  <littledan__>I'd agree if we were introducing a new invalid optimization, that we shouldn't do it. But this could hurt existing sites
21:34:31  <caitp>lets wait and see how bad the regression is and decide where to go from there
21:44:15  <caitp>basically, we're already optimizing iterators, and with --turbo-escape it's probably close to the "cheating" speed in the majority of cases that a typed array would be built from
21:44:33  <caitp>and those figures will probably improve
21:44:55  * mounibecquit (Quit: My Mac has gone to sleep. ZZZzzz…)
21:53:48  * mounibecjoined
22:45:20  * mounibecquit (Quit: Textual IRC Client: www.textualapp.com)
22:49:21  * hferreirojoined
22:56:36  * RT|Chatzillajoined