| 00:15 | <Domenic> | wanderview: sorry for being afk for the day |
| 00:16 | <Domenic> | wanderview: I don't really know why the promises cases take longer to settle, but I could guess that it's more work to JIT through all the extra stuff that's going on. |
| 00:17 | <Domenic> | wanderview: I agree that the async read() only on byobReader design would work. I don't think they should have the same method name though... same-named methods on similar classes should behave the same I think. |
| 00:18 | <Domenic> | wanderview: but I think it's unfair to say performance penalty, as discussed/benchmarked :) |
| 00:54 | <wanderview> | Domenic: I have results that show a more significant perf penalty on mobile devices |
| 00:55 | <wanderview> | Domenic: I was trying to understand the FF native results before posting to the issue, but this is what I have so far: https://docs.google.com/spreadsheets/d/1rl6mbD2z1x1bgJLD6y9KJLYWjppB7BujfiWvUMjYTVs/edit?usp=sharing |
| 00:56 | <wanderview> | Domenic: bluebird promises are always at a penalty compared to sync on my nexus5... native promises are also worse than sync for as few as 32 chunks |
| 00:56 | <wanderview> | I don't have the results in there, but my firefoxos Flame is even worse (as its a lower spec'd phone) |
| 00:58 | <wanderview> | Domenic: btw, the ?chunks= stuff in my test don't work with chrome because it doesn't implement URLSearchParams part of URL spec... do you know of a good alternative? I'd like to run the test there |
| 00:58 | <wanderview> | Domenic: also, I added a size= option to control the size of the chunks... so I can set size=1 to avoid mixing in GC pressure from the buffers |
| 01:00 | <caitp> | is anything blocking URLSearchParams? didn't see any mention of blockers on arv's bug. seems like it would be a good gsoc project |
| 01:01 | <wanderview> | Domenic: also a chunks=auto to run all those chunk sizes in my google doc |
| 01:02 | <caitp> | or maybe too fast for gsoc, but a good starter project maybe |
| 01:03 | <wanderview> | I'm going to redo the google doc results with ?chunks=auto&size=1 for consistency |
| 01:10 | <wanderview> | hmm... I get different sync results when using native promise vs bluebird... probably from GC/CC differences... I think I will split sync out into a separate test |
| 01:11 | <caitp> | not sure how you're doing sync tests at all with promises |
| 01:11 | <wanderview> | caitp: its sync test, promise test, sync test, promise test, etc... interleaved... I think objects left from promise runs are effecting sync runs due to GC |
| 01:11 | <caitp> | mm |
| 01:34 | <wanderview> | *much* more stable results moving sync and promise tests into separate windows |
| 03:00 | <wanderview> | actually... the test results were bogus... many of the results were being limited by setTimeout() clamping at 4ms |
| 03:31 | <wanderview> | summarized my profiling results in the issue: https://github.com/whatwg/streams/issues/320#issuecomment-91418297 |
| 06:43 | <hsivonen> | annevk: what's the story behind the codepoints of windows-1252 that Unicode.org leaves unassigned getting mapped to controls in the Encoding Standard? Did all browsers already agree to do that instead of U+FFFD? |
| 07:13 | <mcnesium> | my new wordpress does have a valid rss feed but safari on iOS and OSX do not show the "reader" sign. any idea what might be wrong? http://mcnesium.com |
| 08:10 | <annevk> | hsivonen: several browsers at least, yes |
| 08:11 | annevk | goes back into hiding |
| 10:53 | <zcorpan> | mathiasbynens: why recommend before </body> now that it uses a getter? |
| 10:58 | <mathiasbynens> | zcorpan: just the general best practice, since <script> blocks |
| 10:59 | <zcorpan> | mathiasbynens: k |
| 11:01 | <zcorpan> | mathiasbynens: i found http://johndyer.name/native-browser-get-set-properties-in-javascript/ |
| 11:02 | <mathiasbynens> | zcorpan: In IE8, `Object.defineProperty` only works on DOM objects, so that’s fine in this case. Not sure if it’s worthwhile to add IE < 8 support |
| 11:06 | <zcorpan> | mathiasbynens: yeah. maybe not. i can point to that in the blog post if people need IE6-7 support (or other old browsers with __defineGetter__) |
| 11:07 | <zcorpan> | mathiasbynens: thanks for doing the polyfill |
| 16:20 | <smaug____> | is there some plan or API proposal for animation frame callbacks in workers? |
| 16:21 | <smaug____> | for the cases like webgl in workers |
| 16:43 | <espadrine> | smaug____: as in, having worker-only canvas contexts? |
| 16:45 | <espadrine> | there's this: https://wiki.whatwg.org/wiki/WorkerCanvas |
| 16:45 | <espadrine> | no idea what state it is in |
| 16:47 | <smaug____> | well, that is the canvas part, but I wonder if there is a plan to expose animation frame callbacks on worker side somehow |
| 17:06 | <zcorpan> | smaug____: sounds a bit like the "UI worker" idea |
| 17:07 | <zcorpan> | ask rick byers |
| 18:20 | <Domenic> | #lazyirc if I dispatch a click event on a radio button or checkbox, that should be the same as .click()ing it, right? and .click() should trigger an event? |
| 18:22 | <Domenic> | I guess testing this myself is the easiest thing to do, instead of reading the specs |
| 18:26 | <TabAtkins> | Domenic: Indeed. (To just testing it yourself, the specs are a rathole on this kind of thing usually.) |
| 18:55 | <Ms2ger> | Domenic, click() triggers event, not the other way around |
| 18:57 | <Domenic> | Right, but triggering the event also checks the box |
| 19:00 | <Ms2ger> | I don't believe it should |
| 19:00 | <Ms2ger> | smaug____, ^ |
| 19:04 | <smaug____> | click() does trigger the link... |
| 19:04 | <smaug____> | in practice implementations dispatch click event and do default handling during the dispathc |
| 19:05 | <smaug____> | dispatch |
| 19:05 | <smaug____> | the spec has still the different model |
| 19:08 | <smaug____> | per spec dispatching click event shouldn't change the checked state, IIRC |
| 19:09 | <smaug____> | nor follow <a href="foo"> |
| 19:09 | <smaug____> | but I think the web disagrees |
| 19:09 | <smaug____> | click is one of the special cases |
| 19:09 | <smaug____> | usually events must be trusted in order to trigger default action |
| 19:09 | <smaug____> | blink has tons of issues with this |
| 23:21 | <wanderview> | Domenic: it appears the native chrome promises clamp to 4ms delays like setTimeout... that seems like a pretty bad bug for promises |
| 23:21 | <Domenic> | wanderview: no waaaaayyyy |
| 23:21 | <wanderview> | I just made the defaults for the benchmark do the automated thing... so running the tests on chrome |
| 23:22 | <Domenic> | wanderview: I think benchmarkjs must be screwing us somehow... I trust it less :( |
| 23:22 | <wanderview> | Domenic: happy to fix it... but so far the data seems consistent to me |
| 23:23 | <Domenic> | wanderview: I am probably going to have to push off working on the benchmark until the weekend/Monday... today is running out of hours |
| 23:23 | <Domenic> | I'm excited about this user-space microtask queue idea |
| 23:23 | <wanderview> | Domenic: np... I will be offline until Monday... getting on a plane and then family time |
| 23:24 | <wanderview> | Domenic: it will be interesting to see the case of the js microtask and a pure js closure per callback.... thats still something to GC, but avoids some of the native promise wackyness |
| 23:26 | <wanderview> | Domenic: the reason I say chrome native promises are clamping... the benchmark shows ~210 ops/sec for the sync case with only 1 chunk... |
| 23:27 | <Domenic> | wanderview: so my guess is benchmarkjs uses setTimeout and so the most async benchmarkjs cases you can run is 250 ops/sec... |
| 23:30 | <wanderview> | Domenic: yes, but the promise.resolve().then(() => deferred.resolve()); should prevent the clamping from occurring, no? |
| 23:30 | <wanderview> | maybe we should try benchmark.js 2.0... jdalton indicated the sync deferred.resolve() is not permitted any more |
| 23:30 | <Domenic> | wanderview: I don't really understand how setTimeout clamping works so I'm not sure ... |
| 23:31 | <Domenic> | I am feeling a desire to go back to your manual tests, but just run them in a loop |
| 23:31 | <wanderview> | Domenic: if setTimeout() nests.. so setTimeout(() => setTimeout(() =>setTimeout()));... if it nests 4 or 5 times it forces the delay to a minimum of 4ms |
| 23:31 | <wanderview> | its in the spec |
| 23:31 | <Domenic> | I think maybe in Chrome setTimeout() is just always clamped to 4ms |
| 23:31 | <Domenic> | I remember bugs |
| 23:32 | <wanderview> | in Firefox the microtask schedule breaks the nesting behavior because it forces the stack back to nothing... I think chrome should do the same, but it does not |
| 23:32 | <wanderview> | ah |
| 23:32 | <wanderview> | yea |
| 23:33 | <wanderview> | even with the clamping the benchmark is still useful to see the curve |
| 23:33 | <wanderview> | we just can't trust the ~210 values |
| 23:36 | <wanderview> | Domenic: I can also see that with chrome the CPU is not maxing out on the low tests... definitely the clamping |
| 23:38 | <wanderview> | I wonder if the perf penalty from promises really is GC of objects |
| 23:41 | <wanderview> | chrome on android does do better with bluebird promises... |