Handling ZonedDateTime with js-joda is extremely slow #395
Comments
|
Does this improve with more executions? I wonder if dynamic optimisation/Graal‘s script compilation improves anything here. The performance problem is unfortunately nothing new with JS-Joda — it definitely is not the fastest library. If you run into such performance bottlenecks, consider importing the Java counterparts.
BTW, you don’t need to create your own logger, just use console log — it automatically uses a logger name based on your rule UID. |
|
Injection caching does not change the behavior. It's the call to |
|
Lines 215 to 220 in 63eb57b to convert the Java ZDT to a JS-Joda ZDT. I have benchmarked this method when it was initially added in #267, just repeated the benchmark with 10000 iterations: Benchmark Scriptvar javaInstantToJsInstant = function (instant) {
return time.Instant.ofEpochMilli(instant.toEpochMilli());
}
var javaZDTToJsZDT = function (zdt) {
const epoch = zdt.toInstant().toEpochMilli();
const instant = time.Instant.ofEpochMilli(epoch);
const zone = time.ZoneId.of(zdt.getZone().toString());
return time.ZonedDateTime.ofInstant(instant, zone);
}
var iters = 10000;
var Instant = Java.type('java.time.Instant');
var ins = Instant.now();
console.log('Benchmarking Instant.parse conversion ...')
var start = time.Instant.now().toEpochMilli();
for (var i = 0; i < iters; i++) {
time.Instant.parse(ins.toString())
}
var end = time.Instant.now().toEpochMilli();
console.log('Benchmark finshed, took ' + (end - start) + ' ms')
console.log('Benchmarking advanced Instant conversion ...')
var start = time.Instant.now().toEpochMilli();
for (var i = 0; i < iters; i++) {
javaInstantToJsInstant(ins)
}
var end = time.Instant.now().toEpochMilli();
console.log('Benchmark finshed, took ' + (end - start) + ' ms')
var ZonedDateTime = Java.type('java.time.ZonedDateTime');
var zdt = ZonedDateTime.now();
console.log('Benchmarking ZonedDateTime.parse conversion ...')
var start = time.Instant.now().toEpochMilli();
for (var i = 0; i < iters; i++) {
time.ZonedDateTime.parse(zdt.toString())
}
var end = time.Instant.now().toEpochMilli();
console.log('Benchmark finshed, took ' + (end - start) + ' ms')
console.log('Benchmarking advanced ZonedDateTime conversion ...')
var start = time.Instant.now().toEpochMilli();
for (var i = 0; i < iters; i++) {
javaZDTToJsZDT(zdt)
}
var end = time.Instant.now().toEpochMilli();
console.log('Benchmark finshed, took ' + (end - start) + ' ms')Now the question is, how many datapoints do you handle? |
|
I am handling between 80.000 and 160.000 datapoints. As you can read on the linked discussion, I tried with Java imports. This accelerates it by a factor of 14. |
|
I will add support for getting the instant from the PersistedItem, Java to JS Instant conversion is much faster: These benchmarks work on the raw Java Persistence Extensions as I need access to the raw Java stuff which is not exposed by the library, as you can see the Java ZDT to JS ZDT conversion is what is time consuming. |
|
That's what I suspected, since I read that js-joda has performance issues in general. So you would offer |
|
Here's also a feature request for providing an implementation which would solve my requirement. Maybe think about exposing a persistence function in openhab-js like |
|
openhab-js |
|
#396 adds access to Instant, however you need to wait for openHAB 4.3.0 M3 or install a current snapshot to have a new enough core version. |
|
I'm using unstable builds. Thanks! |
|
I just published version 5.8.0, which includes PersistedState::instant, will update the add-on soon to use that version. |
Expected Behavior
When using ZonedDateTime wrappers via js-joda in ECMAScript (Rules and Scripts), I would expect a similar performance as with all other properties.
Current Behavior
Looping over a large set of states and using js-joda wrappers within the loop, the loop gets extremely slow. Imagine this example:
The output with a state every 5 seconds leads to more than 14 seconds, whereas the following function costs 0.5 seconds.
Context
I'm trying to get a "Riemann Sum" implementation of measured power. See discussion here:
Arithmetic mean vs average linear/step interpolation
Your Environment
The text was updated successfully, but these errors were encountered: