I'm fixing the flakiness right now.

Regards,
Tim.


On Thu, Jun 13, 2013 at 10:27 AM, <[email protected]> wrote:

> I actually don't like this change, for several reasons:
>
> Bumping up some arbitrary limits is not a solution at all, the flakiness
> already
> came back (see our bots). Note that those tests regularly fail on our bots
> for
> months now, with more than half a dozen half-hearted repair attempts. This
> is
> really annoying for the whole team, because you constantly get "you broke
> the
> build" mails for no good reason.
>
> The other reason why I don't like the change is that the tests are not
> "good
> team players" in the unit test sense: Any unit test taking longer than
> 100ms
> (probably even less) is very bad if you consider the runtime of the whole
> suite.
> If every test took 500ms and we would be able to perfectly distribute this
> on 32
> cores, the suite would take 2min35sec, on a 4 core Laptop almost 21min.
> This is
> not acceptable, running the whole suite should be in the range of 10-20sec,
> otherwise people test even less than they do now.
>
> The bug tracker has a proposed solution with an increasing timeout, this
> should
> really be implemented and it should be checked if the typical case is below
> 100ms. If this doesn't work out, the test should be done in a fundamentally
> different way and if that's not possible we should drop the tests
> completely
> from our suite, the annoyance-to-usefulness ration is a bit too high...
>
> https://codereview.chromium.**org/16280011/<https://codereview.chromium.org/16280011/>
>

-- 
-- 
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
--- 
You received this message because you are subscribed to the Google Groups 
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to