Re: [webkit-dev] Request for Comments: DoYouEvenBench

2014-01-17 Thread Ryosuke Niwa
I've finalized the benchmark and started making measurements on the perf
bots.  You can see results at https://perf.webkit.org/#mode=dashboard

You can run the benchmark inside DRT/WTR using run-perf-tests:
Tools/Scripts/run-perf-tests PerformanceTests/DoYouEvenBench/

To manually run, open PerformanceTests/DoYouEvenBench/Full.html.

You can also use the interactive runner to diagnose  profile WebKit:
PerformanceTests/DoYouEvenBench/InteractiveRunner.html

- R. Niwa

On Wed, Sep 18, 2013 at 5:30 PM, Ryosuke Niwa rn...@webkit.org wrote:

 Hi,

 I just added DoYouEvenBench, a new browser DOM benchmark, in
 http://trac.webkit.org/changeset/156073.

 This benchmark uses http://todomvc.com and emulates user actions: adding
 100 todo items, completing them, and then deleting them with Ember.js,
 Backbone.js, jQuery, and plain-old DOM.

 I'm also in the process of adding one more Ember.js demo app and Flight JS
 demo app to the benchmark.

 The benchmark is at the very early stage of the development, and I'd
 welcome your comments and complaints.

 *Note: The benchmark is not meant to compare the performance between
 different JS frameworks.  Due to the way each application's written and
 user actions are emulated, we can't make a sensible comparison.*

 - R. Niwa

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


Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

2014-01-17 Thread Alexey Proskuryakov

This has been implemented, and one unintended consequence is that this 
noticeably affects how quickly one can iterate on time sensitive patches.

It's a huge waste of time that you are no longer informed when a build fails on 
EWS. This seriously delays urgent work, as you only start working on fixes when 
you happen to manually poll, or even worse, when a reviewer tells you about 
build breakage.

It's good to not spam everyone, however patch author should be notified by EWS 
immediately I think. Some ideas:

- e-mail;
- IRC;
- browser notifications when bug page is open.

The latter might be best, as it also gives some control over whether to get 
pinged - keep the bug open if you care, close it if it's not urgent, and you 
cannot afford distraction now.

I filed https://bugs.webkit.org/show_bug.cgi?id=127203 about this.

- WBR, Alexey Proskuryakov


16 янв. 2014 г., в 15:09, Ryosuke Niwa rn...@webkit.org написал(а):

 Okay, let's remove the python paths but keep the style error messages until 
 we can improve the EWS infrastructure.
 
 - R. Niwa
 
 
 On Thu, Jan 16, 2014 at 9:41 AM, Timothy Hatcher timo...@apple.com wrote:
 On Jan 16, 2014, at 2:28 AM, Alexey Proskuryakov a...@webkit.org wrote:
 
 
 15 янв. 2014 г., в 23:02, Ryosuke Niwa rn...@webkit.org написал(а):
 
 I think that it's good to try not dumping build failures into comments 
 right away, and to see what happens.
 
 As for not showing style bot failures, it seems almost certain that this 
 will make them substantially more annoying to work with. Can you describe 
 the workflow for patch author and reviewer to deal with style bot warnings 
 when they are not inline? Manually finding relevant lines by number can't 
 work.
 
 I agree with Tim that dumping all tested paths along with style warnings is 
 silly. How hard would it be it to get rid of that?
 
 The workflow is to click on the bubble to see the style errors. e.g.
 https://webkit-queues.appspot.com/results/6544662978363392
 
 
 Seems like that would require everyone to manually match errors to code 
 lines indeed, so I object against making this change for style checker 
 warnings.
 
 - WBR, Alexey Proskuryakov
 
 Yeah, seeing the style warnings as a comment (which also causes them to show 
 up in the patch review) is helpful. I was just complaining about the python 
 path spew it also includes.
 
 — Timothy Hatcher
 


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