W3C home > Mailing lists > Public > public-device-apis-log@w3.org > March 2017

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

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Mon, 20 Mar 2017 20:54:34 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-287894704-1490043272-sysbot+gh@w3.org>
> > Thanks for looking into this. After a cursory glance at the comments on the Chromium thread, it doesn't seem to address the case where you have more than one reading per frame
> 
> This would not trigger GC stalls, since sensors of the same type will share reading, thus max number of updated readings per frame would be rather small, and each allocation is also insignificant as I mentioned earlier (less than microsecond)

A microsecond is 6% of a frame's total budget. That clearly doesn't fall in the insignificant category, especially if there are multiple of them, and particularly on cheaper mobile devices.
 
> > when these objects are kept around longer than a frame (Hannes' comment about GC easily taking "several milliseconds" in certain cases is particularly worrying)
> 
> These objects cannot be kept for a long time, either they are GC'd after each frame, or when sensor is stopped, then internal reading is released and the one that is reffed by the user, will be GC'd when reference is lost. It would be worrying if we would keep huge internal cache of readings for a long time and then invalidate them all at once, which is not the case for our implementation.

This assumes that no application-level code interferes with this. Consider the following (inspired by a use case found in a related issue):

```js
var buffer =[];
var sensor = new Accelerometer({ frequency: 120 });

sensor.onchange = _ => { 
    buffer.push(sensor.reading);
    if (buffer.length >= 500) {
        fetch("/log-data", {
            method: "POST",
            body: JSON.stringify(buffer)
        });
        buffer.length = 0;
    }
};
```

This also doesn't address the concern of GC issues in real life scenarios, which is what the OP was worried about.

> > It would also be important to get feedback from other implementors on this topic (which might have different GC strategies).
> Very good point, but taking in to account performance of JSCore or SpiderMonkey, I doubt this will be an issue.

I'd like to hear those implementors speak for themselves.

-- 
GitHub Notification of comment by tobie
Please view or discuss this issue at https://github.com/w3c/sensors/issues/153#issuecomment-287894704 using your GitHub account
Received on Monday, 20 March 2017 20:54:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 12:18:52 UTC