[TIMOB-18855] Windows: Time between creating Date() objects runs a factor 1000 slower then reality
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Critical |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2015-05-04T14:19:19.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 4.1.0 |
| Components | Windows |
| Labels | n/a |
| Reporter | Fokke Zandbergen |
| Assignee | Kota Iguchi |
| Created | 2015-04-25T17:29:14.000+0000 |
| Updated | 2015-07-13T21:14:04.000+0000 |
Description
The following code demonstrates that when you create a
new Date() object in a setTimeout or setInterval method the time is off by a factor 1000.
If you run https://github.com/appcelerator-developer-relations/Mobile-App-Performance/ you will see that this also occurs when you have a expensive computation that takes several seconds and you log the time before and after.
var run = require('run');
var win = Ti.UI.createWindow({
backgroundColor: 'white',
layout: 'vertical'
});
var btnTimeout = Ti.UI.createButton({
top: 20,
height: 40,
color: '#FFF',
backgroundColor: '#000',
title: 'setTimeout'
});
btnTimeout.addEventListener('click', function () {
addLabel();
setTimeout(function () {
addLabel();
setTimeout(function () {
addLabel();
win.add(btnInterval);
}, 5000);
}, 0);
});
win.add(btnTimeout);
var btnInterval = Ti.UI.createButton({
top: 20,
height: 40,
color: '#FFF',
backgroundColor: '#000',
title: 'setInterval'
});
btnInterval.addEventListener('click', function () {
var interval;
var intervals = 0;
addLabel();
interval = setInterval(function () {
intervals++;
addLabel();
if (intervals === 2) {
clearInterval(interval);
}
}, 5000);
});
function addLabel() {
var d = new Date();
win.add(Ti.UI.createLabel({
top: 20,
width: Ti.UI.FILL,
height: 40,
text: pad(d.getHours()) + ':' + pad(d.getMinutes()) + ':' + pad(d.getSeconds()) + ':' + pad(d.getMilliseconds()),
color: '#000'
}));
}
function pad(int) {
var str = int.toString();
if (str.length === 1) {
str = '0' + str;
}
return str;
}
win.open();
I did the tests on the Emulator, but looking at the results [~kota] achieved with https://github.com/appcelerator-developer-relations/Mobile-App-Performance/ the same is true for device.
Attachments
| File | Date | Size |
|---|---|---|
| iOS Simulator Screen Shot 25 Apr 2015 19.25.26.png | 2015-04-25T17:31:17.000+0000 | 41812 |
| Screen Shot 2015-04-25 at 19.24.04.png | 2015-04-25T17:31:17.000+0000 | 101032 |
Attached the results on iOS and Windows Emulator
Confirmed that this issue is Windows-specific which originally because JavaScriptCore evaluates wrong
Date. Following test cases represents the issue, which is failing on Windows, which is passed on OS X.TEST_F(JSContextTests, TIMOB_18855) { JSContext js_context = js_context_group.CreateContext(); js_context.JSEvaluateScript("var start=new Date().getTime();"); std::this_thread::sleep_for(std::chrono::milliseconds(1000)); JSValue js_value = js_context.JSEvaluateScript("new Date().getTime() - start;"); XCTAssertFalse(static_cast<std::int32_t>(js_value) == 1); XCTAssertTrue(static_cast<std::int32_t>(js_value) > 999); // assuming JS evaluation is done within 100 msec... XCTAssertTrue(static_cast<std::int32_t>(js_value) < 1100); }I suspect it is somewhat related to "date time cache" because first "new Date()" call returns valid value. Note that Ti Windows is based on nearly 2 years old JavaScriptCore and there are numerous changes since then, including date time calculation and cache. https://github.com/WebKit/webkit/commits/master/Source/JavaScriptCore/runtime/JSDateMath.cpp
I was able to fix this. It was a small bug originally introduced by Igalia: https://github.com/infosia/webkit-wp8/commit/e4d0d6034ba12c8b2ae9563836b078ace9d59fac The bad news is that I have been failing to build JavaScriptCore for ARM locally, maybe it is environmental issue. Do we have CI build server for JavaScriptCore?
https://github.com/appcelerator/HAL/pull/45
[~kota] is there a build available already that I can run the benchmarks on?
[~fokkezb] Yes, download latest JavaScriptCore [JavaScriptCore-Windows-1430359270.zip](http://timobile.appcelerator.com.s3.amazonaws.com/jscore/JavaScriptCore-Windows-1430359270.zip), and extract it to your JavaScriptCore_HOME. It's safe to overwrite existing *.lib there. Then clean and rebuild your benchmark app.
Verified using: Windows 8.1 Appc CLI (NPM): 4.1.0 Appc CLI (Registry): 4.1.0 Ti SDK: 4.1.0.GA Using the provided sample code the results provided are expected and match the pattern of the iOS results Closing ticket