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.

- `snapshot()` makes new object, I don’t see any difference to what we
 have at the moment.

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

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.

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.

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

Received on Friday, 16 December 2016 17:44:37 UTC