[webkit-dev] perf.webkit.org has been updated

[Ryosuke Niwa]

I've deployed the latest v3 UI on https://perf.webkit.org/
New UI is a lot more polished compared to the old "v1" UI, and
provides more functionality.

One of them is the ability to have multiple dashboards instead of one.
For now, I've picked arbitrary set of tests out of DOM, Parser,
Layout, SVG, and IndexedDB sub-directories of PerformanceTests.
Please let me know if you'd like to have another dashboard and/or
would like to replace any tests shown on any dashboard I've created.

Charts are automatically split (segmented) into pieces by where values
change on the main charts page [1]:
https://perf.webkit.org/v3/#/charts?since=1452499738608=((18-645-null-null-(5-2.5-500)))

On charts page, you can also annotate graphs by creating an analysis
task by clicking "Analyze". Each analysis task can be associated with
a Bugzilla bug. I can add other bug tracking tools if any.

The dashboard itself has the ability to automatically detects
potential regressions based on the aforementioned segmentation
algorithm and automatically start A/B tests on the range.
Unfortunately, we haven't enabled either feature on perf.webkit.org
since we don't have machines or build.webkit.org setup to trigger the
A/B testing for now.

- R. Niwa

[1] https://trac.webkit.org/changeset/182330
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-reviewers] usage of auto

[Saam barati]

> On Jan 12, 2017, at 10:37 AM, Geoffrey Garen  wrote:
> 
>>> e.g. I think this is great:
>>> auto ptr = std::make_unique(bar);
>>> Proposed rule: if the type is obvious because it's on the line, then auto 
>>> is good.
>>> Similarly:
>>> auto i = static_cast(j);
>>> auto foo = make_foo();
>>> auto bar = something.get_bar(); // Sometimes, "bar" is obvious.
>> I'm not sure I agree with this style. There are times where the type of an 
>> auto variable is obvious-enough, but it's almost never more obvious than 
>> actually writing out the types.
> 
> In the first case, static_cast, the type is written out on the same 
> line. Same goes for other casts, make_unique, and so on. Would you accept 
> auto in those cases? If not, what benefit do you get from seeing the type 
> twice on one line?

My reason I don't like this style is it slightly changes how I read code. I 
typically look at the lhs of an expression to get its type.
Now, I may have to look at the lhs, and maybe at some compound expression on 
the rhs. I just don’t see the point of this
to save a few characters.

For cases like jsDynamicCast, std::make_unique, etc, I also have to know what 
those functions do. This is obvious to experienced JSC/C++ developers, but 
maybe not to all newcomers to the code base.

All that said, this usage of auto probably bothers me the least out of all the 
usages I don’t like.

- Saam

> 
> I think the second and third cases are somewhat rare in WebKit, and I might 
> agree against using auto. For example:
> 
> RefPtr thing;
> auto* context = something.context();
> context->setThing(thing.get()); // I need to research why context->thing is 
> allowed to be a raw pointer, but I don’t know what context is.
> 
> Geoff
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev