Re: [sensors] Don't allocate response objects to avoid triggering GC

> @tobie There are few concerns with proposed modifications.
> - When control and data interfaces are merged, extensibility is 
lost. For example, for sensors that can provide additional data in 
'uncalibrated / raw mode' either new interface should be created, or 
all possible data fields have to be present on main interface.

That doesn't bother me, frankly. If you have options that change the 
behavior of the sensor, it seems appropriate that those would be 
reflected on the data. My feeling is that for the case where this will
 really become an issue, the right answer is probably to create 
different interfaces altogether.
> - `snapshot()` makes new object, I don’t see any difference to what 
we have at the moment.

Yeah. That was for the case where a snapshot *is* needed. E.g. for 
storing readings. @rwaldron indicates above that ES6 syntactic sugar 
makes that redundant, though. So let's drop it.

> - `timeStamp` is only accessible through `snapshot()` => for 
algorithms that use timestamp, performance would be the same as with 
the current API.

You're right. This belongs on the main API too. Need to find a better 
name for it, though.
> Chrome canary has implementation of ambient light, accelerometer, 
gyroscope and magnetometer. It would be good to have measurements that
 prove that the current approach would not allow us to reach 
continuous 60fps target. If required, I can quickly prototype infinite
 scroller with recyclable elements, so that we will see whether 
current approach affecting scrolling performance / fps or not.

I don't think there's any doubt that GC pauses is a serious issue for 
high perf real-time use-cases. This has been the case for a decade in 
the Web, is one of the motivations behind ASM.js and WASM (or however 
that thing is called nowadays), and is the reason game developers 
usually pool resources on GC platforms. That said, more perf tests is 
always a good thing.

In order to measure the impact of GC on perf, I suggest looking at 
impact on a real game on low-end devices. Maybe you could look at 
something like this gamebench: and see how it fares on a 
low end Android device once you add 120 new gyroscope objects per 
second and whatever the max polling rate for magnetometer is.

> If you still think that GC would be a problem, we could consider an 
alternative solution. Could we instead provide a method that will fill
 sensor reading data, e.g. `Sensor.getReading(Dictionary out);` or 
` out);`? This will allow to reuse object, yet, 
main interface is not polluted with unwanted fields and extensibility 
is not lost.

Yeah, I'm not hostile to the "bring your own buffer" design pattern. 
iirc WebCrypto uses it quite a bit. It's a lot less user-friendly 
though, so it needs to have serious benefits beyond theoretical purity
 (we can't dismiss [priority of 

GitHub Notification of comment by tobie
Please view or discuss this issue at using
 your GitHub account

Received on Sunday, 18 December 2016 11:05:02 UTC