mozilla :: #perf

18 May 2017
11:07igoldanjmaher|afk: ping
11:28jmaher|afkigoldan: hi
11:28jmaher|afkigoldan: I am going afk soon- can you email me or ping rwood later on this morning?
11:29igoldanjmaher|afk: sure
11:36rwoodigoldan: what's up
12:43igoldanrwood: hello
12:44rwoodigoldan: what's up
12:44igoldanrwood: I created an alert manually
12:44igoldanrwood:
12:44igoldanrwood: https://treeherder.mozilla.org/perf.html#/alerts?id=6698
12:45igoldanrwood: does it look legit? I want to file a bug also
12:47rwoodigoldan: there's a few alerts just before that one also...
12:48rwoodas for the one you created yes I can see why you created it - however there are no retriggers on the 2 jobs after the manual alert you created
12:49rwoodthere are a couple, I would retrigger the jobs immediately after your alert 6698, so you have 5 retriggers on each too just to be sure
12:49igoldanrwood: I did some extra retriggers
12:50igoldanrwood: I filed a bug for the previous regression
12:50rwoodok
12:50rwoodgood stuff
12:51igoldanrwood: should I file bug for 18c74031bd89?
12:51igoldanrwood: or wait a little for the extra retriggers
12:53rwoodigoldan: is that 6698? No wait for the retriggers there was only 1 on the job immediately after it
12:53rwoodnot certain yet that's the commit
12:54igoldanrwood: I now backfilled between 18c74031bd89 and d559a766a802
12:54igoldanrwood: anyway, after the retriggers
12:54rwoodigoldan: thanks
12:54igoldanrwood: I'm pretty sure I'll have to create an extra alert
12:55igoldanrwood: there looks like a 3rd regression after 18c74031bd89
12:55igoldanrwood: it's greater than 3%
12:56rwoodwell you'll see once the jobs are done :)
12:56igoldanrwood: yep
12:56igoldanrwood: I've got some questions now
12:57igoldanrwood: if you're working a couple of days on a feature or fix
12:57smaughow do I run ts_paint?
12:57smaugor whatever is the startup test
12:59igoldansmaug: locally?
12:59smaugyes
13:00smaugI thought there were instructions in the wiki page, but perhaps I was looking at some wrong wiki page
13:00igoldansmaug: this is the wiki page
13:01igoldansmaug: you first need to download a zip file
13:01igoldansmaug:
13:01smaugoh
13:01igoldansmaug: https://wiki.mozilla.org/Buildbot/Talos/Tests#tp5n_pages_set
13:01smaugthat is tp5
13:01smaugI'm not interested in that
13:01smaugjust startup
13:02igoldansmaug: then you can run: ./mach talos-test --activeTests other-e10s
13:04igoldansmaug: did it start the test?
13:05smauglet me try that
13:06smaug16:05:51 FATAL - Test name is missing or invalid
13:06igoldansmaug: for future reference, this is the wiki: https://wiki.mozilla.org/Buildbot/Talos/Running
13:07smaugaha, I think I was trying to find the information in https://wiki.mozilla.org/Buildbot/Talos/Tests
13:07igoldansmaug: one moment
13:07igoldansmaug: I mistaken the tests with the suite name
13:08igoldansmaug: try again with this: ./mach talos-test --activeTests ts_paint
13:08igoldansmaug: sorry
13:09smaugnow I recall why I gave up with local talos running last time too: https://pastebin.mozilla.org/9022086
13:10smaugoh well, tryserver will give me the results
13:18igoldanrwood: so, if you're working more days on a fix
13:18igoldanrwood: you merge with the inbound daily?
13:19igoldanrwood: to keep up to date?
13:19igoldanrwood: or, at least, after you know a change was made for Talos
13:24rwoodigoldan: so that's kind of up to you... when you go to submit your finished patch autolander will try to merge it for you anyway, but yes if there's a conflict then you'll have to resolve the conflict yourself
13:24rwoodso depends - if you know there's a potential conflict then yeah you might want to pull in the latest into your patch first and resolve the conflict before landing
13:24igoldanrwood: cool
13:25rwoodalso depends of course if any updates effect the behaviour of your patch
13:25igoldanrwood: yes
13:26igoldanrwood: I saw Pages did a lot of contribution to Talos
13:26igoldanrwood: can I contact him, if I have certain questions?
13:26rwoodigoldan: oh yeah? that's great
13:27rwoodigoldan: if you have questions about certain patches I would put the question in the bug for the patch and needinfo the contributor
13:27rwoodgood to have a history in case it leads to patch changes
13:34rwoodI am off to the dentist now, have a good day igoldan
13:35igoldanrwood: ok
13:35igoldanrwood: have a great day!
14:44jmaherigoldan: hi, did you get your questions answered
15:54mconleyFolks: if you're interested in knowing more about perf.html and profiling, ehsan is doing a presentation in a few moments in the Brown Bag vidyo room
15:54mconleystarts at 12PM ET
17:49_6a68jmaher: hey, I'm kinda baffled by this perf comparison: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=381e7cc55957&newProject=try&newRevision=9f6705f12c44b775837e6bb56472593e52f62d7d&framework=1
17:49_6a68The base commit is Screenshots with the button managed by bootstrap code, where we lazily load the webextension only when the button is clicked
17:50_6a68The new commit is Screenshots with the button managed by bootstrap code, adding a dummy contextmenu item that is also managed by bootstrap code
17:50_6a68Both sit on top of the same central base commit
17:50_6a68I cannot imagine how _adding_ a tiny bit more code would dramatically _improve_ performance
17:52_6a68Both runs ran 5x, there is very high confidence...could this be something with the underlying hardware? Is there a virtualization layer that could be leaking different amounts of IO or CPU?
17:53jmaher_6a68: let me look
17:53_6a68thx!
17:53jmaher_6a68: so adding the dummy contextmenu is causing the regression?
17:53_6a68no, it's actually making the code much more performant -- lots of green in the comparison
17:54_6a68wait, maybe I sent you the wrong link, I'm sorry, one sec
17:54jmaheryeah, I only see regressions- seeing red!
17:54_6a68jmaher: here https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=7f5bab456be0&newProject=try&newRevision=d0b728d2a45a5bf22cfa6acf70ced0402d76c2f5&framework=1
17:55_6a68I have too many perfherder tabs open :-P this is the correct link
17:55_6a68how on earth could nonmain fileio be 55% improved by adding a context menu item? baffling
17:58_6a68jmaher: so here is lazybutton vs the previous commit as chosen by perfherder, there are some regressions https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-inbound&originalRevision=41958333867b&newProject=try&newRevision=9f6705f12c44b775837e6bb56472593e52f62d7d&framework=1
17:58_6a68and here is lazybutton + lazy context menu, just one regression, same base commit chosen by perfherder https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-inbound&originalRevision=41958333867b&newProject=try&newRevision=d0b728d2a45a5bf22cfa6acf70ced0402d76c2f5&framework=1
17:59_6a68I can double-check that I exported the code correctly, that it actually executed, and retry talos runs for both commits against today's central, I'm planning to do that regardless
17:59_6a68But I wondered if this points to something in the testing platform that you're already aware of
18:01_6a68Oh, maybe what happened is that windows 8 and osx tests didn't run in the second case
18:02_6a68jmaher: is there an osx 10.10 backlog? I see now that those tests didn't run overnight
18:04jmaher_6a68: there are 7000 osx jobs in the queue, I estimate that is 14-16 hours of runtime
18:04_6a68yikes!
18:04jmaherdon't worry about nonmain fileio, that is odd on try
18:04_6a68if I run nonmain fileio on a local machine, would that be more reliable?
18:05jmaher_6a68: no; you can only run that on win7 with the xperf toolkit
18:05jmaherit is an issue with addons, not necessarily pushes to try
18:05_6a68oh, ok
18:06jmaheras for your push, the base is a regression
18:06_6a68ha! ok
18:06jmaherthe new is inline with the existing numbers
18:06jmaherhttps://treeherder.mozilla.org/perf.html#/graphs?timerange=172800&series=%5Btry,66dbde001b68b274cd7b350641f995cc06c6e1a9,1,1%5D&series=%5Bautoland,66dbde001b68b274cd7b350641f995cc06c6e1a9,1,1%5D&series=%5Bmozilla-inbound,66dbde001b68b274cd7b350641f995cc06c6e1a9,1,1%5D&highlightedRevisions=7f5bab456be0&highlightedRevisions=d0b728d2a45a&selected=%5Btry,66dbde001b68b274cd7b350641f995cc06c6e1a9,205117,274362106,1%5D
18:07_6a68jmaher: so maybe the best thing is to rebase against current central, re-run the tests, and see how it looks later today?
18:08_6a68if the osx queue is very long, should I just run linux64 jobs for today?
18:09jmaher_6a68: yeah, that makes sense and doing just linux64 is good; once that is a-ok, then go forward with other platforms
18:10_6a68 thanks for your help
20:30RyanVMjmaher|afk: fun fact, nvidia driver 340.52 is the #1 version in use on Win7 for the GT610, which isn't much newer than the one we're using in CI at the moment
20:33RyanVMOMG, ignore the specific device ID and one even older becomes #1
20:33RyanVM195.62
20:33RyanVM(8.15.11.8593)
20:33RyanVMlordy
20:43RyanVM340.52 is #1 for Win8/8.1 too
20:44RyanVMso our currently in use 335.23 isn't horribly off, though we could probably stand to update a bit
19 May 2017
No messages
   
Last message: 9 days and 5 hours ago