Revert "Cross-compiling from Linux to Android requires -lrt for the host toolset.", "Fix Visual Stu…

Revert "Cross-compiling from Linux to Android requires -lrt for the host toolset.", "Fix Visual Studio debug build after r16398." and "Reland "Add Chromium-style TimeDelta, Time and TimeTicks classes, and a new ElapsedTimer class.""

This reverts commit r16398, r16399 and r16402 for breaking the Windows
WebKit tests. Will reland fix which doesn't use High Resolution Timer
for ElapsedTimer (we suspect QueryPerformanceCounter overhead is
responsible for test breakage).

TBR=machenbach@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=16405

[Benedikt Meurer, 2013-08-28 14:32:42]

Committed patchset #1 manually as r16405.

[Michael Achenbach, 2013-08-28 14:36:44]

On 2013/08/28 14:32:42, Benedikt Meurer wrote:
> Committed patchset #1 manually as r16405.

lgtm

[yurys, 2013-08-28 15:12:48]

I'm curious what the plan regarding high resolution ElapsedTimer is. Are you
going to support special mode for it? We obviously need highres one for cpu
profiler.

[Benedikt Meurer, 2013-08-28 17:14:55]

On 2013/08/28 15:12:48, Yury Semikhatsky wrote:
> I'm curious what the plan regarding high resolution ElapsedTimer is. Are you
> going to support special mode for it? We obviously need highres one for cpu
> profiler.

Of course. It looks like the problems we faced on Windows were caused by a
missing millisecond to microsecond conversion in the fallback tick clock. I have
a fix for that already, and will test tomorrow.
If this turns out to work, then there's now reason for ElapsedTimer not to use
HighResNow, and we'll keep it that way.
If HighResNow is still an issue afterwards, we'll add some HighResElapsedTimer
or something like that.

[yurys, 2013-08-29 07:56:18]

On 2013/08/28 17:14:55, Benedikt Meurer wrote:
> On 2013/08/28 15:12:48, Yury Semikhatsky wrote:
> > I'm curious what the plan regarding high resolution ElapsedTimer is. Are you
> > going to support special mode for it? We obviously need highres one for cpu
> > profiler.
> 
> Of course. It looks like the problems we faced on Windows were caused by a
> missing millisecond to microsecond conversion in the fallback tick clock. I
have
> a fix for that already, and will test tomorrow.
> If this turns out to work, then there's now reason for ElapsedTimer not to use
> HighResNow, and we'll keep it that way.
> If HighResNow is still an issue afterwards, we'll add some HighResElapsedTimer
> or something like that.

Great, thanks for clarifying!