Re: The current state of Talos benchmarks
On Thu, Aug 30, 2012 at 3:34 AM, Mike Hommey m...@glandium.org wrote: Ideally, we should make talos regressions visible on tbpl as oranges, and star them as other oranges. FWIW, making this possible is an explicit goal of the SfN effort. -Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The current state of Talos benchmarks
I've just filed bug 786978 for this. - Matt - Original Message - From: Ehsan Akhgari ehsan.akhg...@gmail.com To: rob...@ocallahan.org Cc: dev-platform@lists.mozilla.org Sent: Thursday, August 30, 2012 1:02:43 PM Subject: Re: The current state of Talos benchmarks On 12-08-29 8:41 PM, Robert O'Callahan wrote: Some of the 16-17 regressions are known and due to DLBI patches (bug 539356). Since we don't have full DLBI on trunk yet, those changes should just be preffed off on Aurora for 17. We should do that and see how that affects the numbers. Matt Woodrow will take care of that :-). That's good to hear. Is there a bug on file for that? Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Attribute getter naming in WebIDL bindings
On Wed, Aug 29, 2012 at 5:20 PM, Boris Zbarsky bzbar...@mit.edu wrote: Right now, attribute getters always get prefixed with Get in the WebIDL bindings. So readonly attribute long foo becomes int32_t GetFoo() in the C++. Would it make sense to drop the Get in certain cases? In particular, in cases in which: 1) The getter is infallible. 2) The return value is not returned via an outparam. 3) The return value is not an interface type or is not nullable. So this IDL: readonly attribute long foo; readonly attribute Iface bar; readonly attribute Iface? baz; What would readonly attribute long? bin; compile into? If it compiles into something called GetBin then we'd have a nice consistency that any getters for nullable types are named GetX and any getters for non-nullable types are named X. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The current state of Talos benchmarks
On 08/29/2012 09:54 PM, Robert O'Callahan wrote: On Thu, Aug 30, 2012 at 1:00 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: I agree with that if we talk about performance in general. But this thread is about specific regressions in performance as a result of changeset going into our tree. I don't think the same argument applies here, unless we decide that we don't care about some of the things that we measure on Talos (in which case we should stop running those tests if we're not going to act on their results.) Yeah. Troubled as Talos is, we have had a lot of cases where Talos reported a regression that we tracked down to a real bug in some checkin, and backing out the checkin and fixing it was absolutely the right thing to do. Talos is useful. Agreed. Talos does find real regressions from individual developer commits. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The current state of Talos benchmarks
On 08/29/2012 07:32 PM, Nicholas Nethercote wrote: In my experience, a lot of those emails say there was a regression caused by one of the following 100 patches, and I will have written 1 of those patches. I usually ignore those ones (though it depends on the nature of the patch). But if I get an email saying something like there was a regression caused by one of the following 3 commits, I'll look into it. I usually go back to mozilla-inbound when I see a talos regression on a mozilla-central merge push. Looking on inbound makes it easier to spot the individual push that may have triggered the regression. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Attribute getter naming in WebIDL bindings
On 8/30/12 4:16 AM, Ms2ger wrote: It certainly looks nicer, but I'm not a big fan of complicating the rules for assembling the C++ signature from the WebIDL. XPIDL's consistency here, IMO, saves time when implementing an interface: you can focus on the actual implementation, rather than the binding code. One of the goals, honestly, is to have the xpidl getters look exactly like the C++ getters you'd have if you just wrote C++ getters (or for that matter like the ones you probably already have). That is, ideally WebIDL maps to the API you'd pick for your C++ class for C++ consumers anyway. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Attribute getter naming in WebIDL bindings
On 8/30/12 8:26 AM, Jonas Sicking wrote:
What would
readonly attribute long? bin;
compile into? If it compiles into something called GetBin then we'd
have a nice consistency that any getters for nullable types are named
GetX and any getters for non-nullable types are named X.
I was going to make it GetBin after thinking about it, yeah.
Specifically, it would be:
Nullableint32_t GetBin();
So my specific logic was going to be like so:
if (fallible || retval_nullable || retval_outparam) {
// prepend Get
}
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Attribute getter naming in WebIDL bindings
On Thu, Aug 30, 2012 at 10:06 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/30/12 8:26 AM, Jonas Sicking wrote:
What would
readonly attribute long? bin;
compile into? If it compiles into something called GetBin then we'd
have a nice consistency that any getters for nullable types are named
GetX and any getters for non-nullable types are named X.
I was going to make it GetBin after thinking about it, yeah.
Specifically, it would be:
Nullableint32_t GetBin();
So my specific logic was going to be like so:
if (fallible || retval_nullable || retval_outparam) {
// prepend Get
}
Sounds great!
/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: The current state of Talos benchmarks (meeting notes)
On 12-08-30 5:42 PM, Taras Glek wrote: * Joel will revisit maintaining Talos within mozilla-central to reduce developer barriers to understanding what a particular Talos test result means. This should also make Talos easier to run I have filed bug 787200 for this discussion. Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The current state of Talos benchmarks (meeting notes)
On Thursday 2012-08-30 14:42 -0700, Taras Glek wrote: * Joel will revisit maintaining Talos within mozilla-central to reduce developer barriers to understanding what a particular Talos test result means. This should also make Talos easier to run This will also solve one of the other problems that leads developers to distrust talos, which is that a significant portion of the performance regressions reported are (or at least were at one time) the result of changes to the tests, but that changes to the tests don't show up as part of the list of suspected causes of regressions. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
