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

> Anyways, the change for the interfaces was already done, unfortunately, without any data or even JS example that represents the problem. I think we should avoid that in the future and do proper investigation before rushing to change everything.

As explained when that changed was done, the `sensor.reading` was a departure from the original design to accommodate referencing the same object from both the sensor and the event. Once the WG decided referencing readings from the event was a bad idea, there was no longer any technical reason to this design that I was aware of, plus a high risk of GC issues given prior experience working with JS-heavy apps on mobile devices.

That said, if we have a new need for this, it makes complete sense re-exploring, but we'll need serious testing to be absolutely sure this doesn't create GC issues on any platform. Fwiw, I'm absolutely not convinced by your test case given the kind of cases where I've seen such issues crop-up in the past.

>> This assumes that no application-level code interferes with this. Consider the following (inspired by a use case found in a related issue):
> This is not a valid example, in the same way developers can populate buffer using buffer.push({sensor.x; sensor.y; sensor.z}); and then try invalidating it during critical rendering path, e.g., re-layouting.

You're right from a theoretical perspective. But in practice, a JS dev not attuned to the inner workings of Chrome GC, will probably assume `buffer.push({sensor.x; sensor.y; sensor.z});` has a GC cost while `buffer.push(sensor.reading);` doesn't "as the object was already created." (That would have been *my* assumption.)

That said, that begs the question as to whether we really want to expose sensor.x, sensor.y, and sensor.z on high-frequency sensors (I have no idea—I'm just throwing that out).

-- 
GitHub Notification of comment by tobie
Please view or discuss this issue at https://github.com/w3c/sensors/issues/153#issuecomment-287915334 using your GitHub account

Received on Monday, 20 March 2017 22:16:23 UTC