4 ms·

Unfortunately, V8 implements slice() fast at the expense of correctness. A basic edge-case testcase like https://bug1087963.bugzilla.mozilla.org/attachment.cgi

Unfortunately, V8 implements slice() fast at the expense of correctness. A basic edge-case testcase like https://bug1087963.bugzilla.mozilla.org/attachment.cgi?id=8510317 https://bug1087963.bugzilla.mozilla.org/attachment.cgi?id=85... fails. That said, it's clearly possible to do this fast _and_ correctly (e.g. IE manages this). But as a note, some V8 folks would like to remove the buggy-but-fast thing completely. See https://code.google.com/p/v8/issues/detail?id=3612#c2 https://code.google.com/p/v8/issues/detail?id=3612#c2

cromwellian 12y ago
Thanks Mozilla for the quick reaction. We were not really blocked on this as a for-in/Object.getOwnPropertyNames loop is an easy workaround, it's more that finding the cause of an unexplained slow down took a bit of time (the usage comes from another engineer's rpc-serialization library) Is there a point of contact for rendering/paint performance issues? We've had problems in Chrome where we had to work around excessive invalidation/paints, but those were diagnosed by using Chrome's layer/paint debugging tools and talking to Blink engineers, things may go quicker if when we encounter problems, there's someone we can email for help or a fix.
- VerGreeneyes 12y ago
  If you just file a bug on Bugzilla (https://bugzilla.mozilla.org/ https://bugzilla.mozilla.org/) in the Core: Graphics component with a reproducible testcase that will probably get people looking at it pretty quickly. For more one-on-one contact I'd suggest the #gfx channel on the Mozilla IRC, although that tends to work best if you know who to reach out to specifically. The gfx newsgroup (https://groups.google.com/forum/#!forum/mozilla.dev.tech.gfx https://groups.google.com/forum/#!forum/mozilla.dev.tech.gfx) might also work to call attention to a particular issue. You can probably setup an e-mail contact through one of those channels if that's what you prefer.
- tschneidereit 12y ago
  (SpiderMonkey engineer here) What VerGreeneyes says is true for our JS engine, too: you can always file bugs in our bugzilla (in the "Core/ JavaScript Engine" component). We react to such bugs very promptly (as you can see in bug 1087963[0] which was fixed six hours after being filed) and, in many cases, can uplift patches from Nightly to Aurora and maybe Beta, so they'll reach release builds more quickly. If for some reason you're not comfortable with filing a publicly visible bug, you can also abuse the flag for filing security-sensitive bugs. That way, we may be better able to help with issues affecting unannounced products. For asking questions or getting our attention even more quickly, you can either join us in the #jsapi channel on irc.mozilla.org, send mail to dev.tech.js-engine[1], or send mail to one of the SpiderMonkey engineers directly. A list of these engineers is available at [2], or you can just email me at [my nick]@mozilla.com. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1087963 https://bugzilla.mozilla.org/show_bug.cgi?id=1087963 [1] https://lists.mozilla.org/listinfo/dev-tech-js-engine https://lists.mozilla.org/listinfo/dev-tech-js-engine [2] https://wiki.mozilla.org/index.php?title=Modules/Core#JavaScript https://wiki.mozilla.org/index.php?title=Modules/Core#JavaSc...
  - cromwellian 12y ago
    Thanks for the info. I'll make sure we file bugs as repro-case-able issues come up, but if we get stuck on a deeper mystery, we may need some more direct help. We've made a lot of progress, and from a logic and speed issue, a lot has been resolved and mostly working, but animations are janky, and from "subjective" speed point of view, it unfairly makes FF look bad. Based on previous experience with Chrome, hitting the sweet spot of 60fps is usually where the JS developers need help from the rendering engine folks.
    - tschneidereit 12y ago
      That makes a lot of sense, yes. We can profile cases like that and get info/help from people working on the relevant components. It happens fairly frequently that we move perf bugs from the JS component into GFX or DOM bindings or something else entirely. So really, just file a bug in one of these components, maybe CC a person you already interacted with or send an email, and we'll do the triage.

cromwellian 12y ago

Thanks Mozilla for the quick reaction. We were not really blocked on this as a for-in/Object.getOwnPropertyNames loop is an easy workaround, it's more that finding the cause of an unexplained slow down took a bit of time (the usage comes from another engineer's rpc-serialization library) Is there a point of contact for rendering/paint performance issues? We've had problems in Chrome where we had to work around excessive invalidation/paints, but those were diagnosed by using Chrome's layer/paint debugging tools and talking to Blink engineers, things may go quicker if when we encounter problems, there's someone we can email for help or a fix.

VerGreeneyes 12y ago
If you just file a bug on Bugzilla (https://bugzilla.mozilla.org/ https://bugzilla.mozilla.org/) in the Core: Graphics component with a reproducible testcase that will probably get people looking at it pretty quickly. For more one-on-one contact I'd suggest the #gfx channel on the Mozilla IRC, although that tends to work best if you know who to reach out to specifically. The gfx newsgroup (https://groups.google.com/forum/#!forum/mozilla.dev.tech.gfx https://groups.google.com/forum/#!forum/mozilla.dev.tech.gfx) might also work to call attention to a particular issue. You can probably setup an e-mail contact through one of those channels if that's what you prefer.
tschneidereit 12y ago
(SpiderMonkey engineer here) What VerGreeneyes says is true for our JS engine, too: you can always file bugs in our bugzilla (in the "Core/ JavaScript Engine" component). We react to such bugs very promptly (as you can see in bug 1087963[0] which was fixed six hours after being filed) and, in many cases, can uplift patches from Nightly to Aurora and maybe Beta, so they'll reach release builds more quickly. If for some reason you're not comfortable with filing a publicly visible bug, you can also abuse the flag for filing security-sensitive bugs. That way, we may be better able to help with issues affecting unannounced products. For asking questions or getting our attention even more quickly, you can either join us in the #jsapi channel on irc.mozilla.org, send mail to dev.tech.js-engine[1], or send mail to one of the SpiderMonkey engineers directly. A list of these engineers is available at [2], or you can just email me at [my nick]@mozilla.com. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1087963 https://bugzilla.mozilla.org/show_bug.cgi?id=1087963 [1] https://lists.mozilla.org/listinfo/dev-tech-js-engine https://lists.mozilla.org/listinfo/dev-tech-js-engine [2] https://wiki.mozilla.org/index.php?title=Modules/Core#JavaScript https://wiki.mozilla.org/index.php?title=Modules/Core#JavaSc...
- cromwellian 12y ago
  Thanks for the info. I'll make sure we file bugs as repro-case-able issues come up, but if we get stuck on a deeper mystery, we may need some more direct help. We've made a lot of progress, and from a logic and speed issue, a lot has been resolved and mostly working, but animations are janky, and from "subjective" speed point of view, it unfairly makes FF look bad. Based on previous experience with Chrome, hitting the sweet spot of 60fps is usually where the JS developers need help from the rendering engine folks.
  - tschneidereit 12y ago
    That makes a lot of sense, yes. We can profile cases like that and get info/help from people working on the relevant components. It happens fairly frequently that we move perf bugs from the JS component into GFX or DOM bindings or something else entirely. So really, just file a bug in one of these components, maybe CC a person you already interacted with or send an email, and we'll do the triage.