- From: Alexander Shalamov via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Mar 2017 18:47:49 +0000
- To: public-device-apis-log@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 that microsecond) > 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 cache of internal readings for a long time and then invalidate them all at once, which is not the case for our implementation. > 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. -- GitHub Notification of comment by alexshalamov Please view or discuss this issue at https://github.com/w3c/sensors/issues/153#issuecomment-287859966 using your GitHub account
Received on Monday, 20 March 2017 18:47:56 UTC