[01:10:18] Platonides: thanks. [13:15:32] Krinkle: o/ pinging for code review. ;) [17:13:48] bmansurov: thx, on it [18:58:11] * leila waves to tizianop. [18:58:32] hey leila! [18:58:33] halfak: any chance we can hop on a call I ask you a couple of questions re https://meta.wikimedia.org/wiki/Research:Testing_capacity_of_expressions_of_gratitude_to_enhance_experience_and_motivation_of_editors ? I expect it to take 5-min of your time. [18:58:44] tizianop: what's going on? :) [18:58:56] ooh. Just from the title, it looks fun. [18:59:08] halfak: your name is on it. [18:59:08] :D [18:59:29] sgoel: eh! I didn't notice you made it to here. Welcome. [18:59:29] ha. I didn't know they chose that title ^_^ [18:59:34] I'm on a email blitz at the moment. Could this wait until tomorrow? [18:59:39] Let me give some intros then, sgoel, when you're around. ;) [18:59:42] If not, 5 mins is OK [18:59:59] halfak: actually, let me type here and you can respond whenever you can. [19:00:11] kk [19:00:59] leila: everything ok! you? [19:01:00] halfak: soooo, with sgoel, we're going to dig deeper to understand Thanks feature better. sgoel pointed out the study I linked, and she wanted to make sure there is no major overlap. I read the description and I am pretty sure there is no overlap, but I figured I double-check with you. [19:01:08] halfak: it would be great if you confirm. :) [19:01:22] tizianop: I'm holding my breath as we will be opening a position in any minute. ;) [19:01:41] leila, oh wow! [19:01:55] tizianop: other than that, I know the schema is under review with Performance and bmansurov is actively working on it. He has some plans to finish the work on it this week. [19:02:07] leila, I know less about this study than their other one. [19:02:17] tizianop: we may need your help with hiring in SIGIR. ;) [19:02:30] halfak: what do you mean by "this"? [19:02:35] It'll be hard for me to confirm, but I expect that Nathan/Julia would be happy to discuss. [19:02:52] The study you linked (re. gratitude) [19:04:02] halfak: got you. In that case and since you don't see an immediate overlap, and what I read in the details of the project description, there is really no overlap. The gratitude one is focused on readers to editors thanks, the one we're talking about is about a current feature which is editor-to-editor thanks. Hopefully they complement each other and help us learn better about the full space. [19:06:21] leila, I agree [19:06:52] I'll make sure that, if they start thinking about editor-editor gratitude that they become familiar with your project. [19:06:54] Got the docs? [19:07:52] leila: between June 26th and July 6th, I'm in Palo Alto! If you and Dario are around, I can pass by in your office to say hi :D [19:08:06] halfak: I just pinged sgoel to start with a page on meta. we shall share docs shortly. :D [19:08:35] Great! I think it'll be good to cross link the studies to make sure no one forgets and we can compare results later [19:09:23] Hi Leila! [19:09:56] tizianop: DarTar is in CEST to cover for your absence. ;) [19:10:28] leila, haha ok! :D [19:10:30] tizianop: buttttt, I'll be around, so we should definitely meet up and use the time you're here to move the boundaries of science and social life. ;) [19:10:41] halfak: agreed. [19:10:49] soooo, a quick intro. [19:11:19] leila, yup. Absolutely! [19:11:50] Hi! Nice to meet you :) [19:11:53] dsaez, bmansurov, tizianop, halfak, J-Mo, et al.: sgoel_ has started working on understanding Thanks feature as of yesterday. She will be in this channel, at least for the next 8 weeks, more frequently. [19:12:10] o/ Nice to meet you :D [19:12:21] hi sgoel_ [19:12:26] some very early notes of what we discussed are at https://etherpad.wikimedia.org/p/Thanks . and meta page will go up soon. [19:12:42] Welcome and good luck on your research project. I'm excited discuss methods and to see the results when you get there :D [19:13:07] Thank you! [19:13:19] sgoel_ please, feel free to contact me anything were you think i can help you [19:13:23] hi sgoel_! That sounds like a fascinating project. Been curious about how people use that feature myself. [20:15:32] * leila digs the fridge for lunch. [20:16:52] o/ sgoel_! Welcome. [20:17:31] thanks :) [20:57:16] Krinkle: hey. How are you getting the numbers for steps 1, 2, and 5 in your analysis? Do you have console.log statements in the code? [20:58:00] Krinkle: also, why do you think #6 is due to CitationUsage? I ran the code with schema sampling rate set to 0, and I see the same violations. [20:58:57] bmansurov: Oops, there was supposed to be a link after "Apply instrumentation patch" [20:59:03] bmansurov: https://gist.github.com/Krinkle/41e6dc76df4ab49bb4fe48e57bbb1634 [20:59:19] Krinkle: thanks. i've disabled WikimediaEvents, but still getting those violations. [20:59:44] snippet? [21:00:06] [Violation] 'requestAnimationFrame' handler took 53ms [21:00:07] 16:59:20.887 load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=1h29e03:50 [Violation] 'setTimeout' handler took 53ms [21:00:07] 16:59:21.378 load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=1h29e03:50 [Violation] 'setTimeout' handler took 489ms [21:00:08] 16:59:21.927 load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=1h29e03:50 [Violation] 'setTimeout' handler took 457ms [21:00:11] 16:59:21.928 [Violation] Forced reflow while executing JavaScript took 419ms [21:00:32] Right, but not one with requestIdleCallback? [21:00:54] Anyway, when the stack starts from a promise resolution, the tracking for rAF/rIC/setTimeout natively doesn't apply [21:01:18] unless the promise is immediately resolved e.g. on repeat view. [21:01:34] 'requestIdleCallback' handler took 73ms (when the sampling is 0) [21:01:39] Which is why I added the console.time() markers so you can see the time spent in the added code separately. [21:02:01] I see [21:02:02] Right, so there was another burst of execution on the page. Possibly the 'init' scope of another module. [21:02:22] That's why I'm not sure why we're attributing it to CU only [21:02:33] but yeah, you're right that the requestIdleCallback violation I saw may not've been from the stack containing the 50ms+ burst from CU js [21:03:45] OK, I'll profile around and see if I can find the any more granular data. Thanks [21:03:48] But I'm more worried about the time spent, not how the stack started. The stack can also start from a browser event or from a promise resolution., in which case chrome doesnt' currently report it by default. [21:04:01] i see [21:04:08] But yeah, I've got work to do to address the others that creeped in. [21:04:13] :) [21:04:42] bmansurov: btw, the quickest hack to make this work would be to change foo() bar() baz to mw.requestIdleCallback(foo); mw.requestIdleCallback(bar); mw.requestIdleCallback(baz); [21:05:16] oh cool [21:05:20] Which means the browser will run them back-to-back iff there is budget available, otherwise it'll yield ~1ms to flush OS events queue, and then go back to executing. [21:05:28] that is, assuming no single one of the setup handlers takes 50ms [21:05:51] ok [21:06:10] it also gives you the native tracking back so you don't need console.time :P [21:06:41] hooray [21:44:13] dsaez: are you still around? [22:00:37] Krinkle: this patch have reduced the setup time to about 7ms: https://gerrit.wikimedia.org/r/#/c/432534/8..10 [22:00:49] Krinkle: do you see any problems with it? [22:01:51] bmansurov: The mouseover/mouseout having a run-time selector filter might be a problem. [22:02:24] Krinkle: even if the selector is limited to 'sup.reference a'? [22:02:27] given it would presumably trigger for every pixel cursor movement. [22:02:47] let's see. [22:02:51] one second [22:03:42] it doesn't seem to [22:29:55] bmansurov: Yeah, overhead is about +5ms per event, which isn't great, but as long as it doesn't fire continuously, might be okay. [22:29:56] https://gist.github.com/Krinkle/a1f1520138e58cee8015f12f0c1cf53b [22:30:33] I guess Chrome's put some throttling in. used to be much worse [22:30:47] Also, given it's not mousemove, it's only when the event.target changes. [22:30:54] So that helps too. [22:31:13] Krinkle: ok, so the overhead is associated with any mouse movement or just for those links? [22:31:30] oh i see above [22:32:08] what's the verdict? do we want to go with this solution or find another solution? [22:32:22] bmansurov: the mouseover/mouseout event is attached to #content, so any cursor movement within the page where the direct element underneath the cursor (e.g. entering bold/italic/link/infobox/heading etc.) changes [22:32:34] bmansurov: The single handler definitely speeds up setup time considerably [22:32:42] I assume that's why you changed it back in the last patch set? [22:32:56] yes, that was the biggest contributor to the setup time [22:33:02] Yeah, figures. [22:33:18] Do you have a number of what it brought it down to? [22:33:31] e.g. it started out around 50-70ms before this change for me. [22:33:42] yes it was in that region [22:33:48] and now it's under 10 [22:33:51] okay [22:34:29] Thanks for bearing with me on this one. It took a bit longer than intended. [22:34:51] sure and thanks for helping with it, our work was stuck for a long time