[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebGL bufferSubData lacks "size" parameter

On Thu, Jan 12, 2012 at 9:58 AM, Gregg Tavares (wrk) <gman@google.com> wrote:

On Thu, Jan 12, 2012 at 8:20 AM, Florian Bösch <pyalot@gmail.com> wrote:
On Thu, Jan 12, 2012 at 4:22 PM, Vladimir Vukicevic <vladimir@pobox.com> wrote:
> I think it's a given that GC is a major pitfall in writing responsive apps
> in any garbage-collected language.  There's a lot of work going on I believe
> in all the engines to improve and tune GC.
Python does not stop the world for noticable fractions of a second
unless under extreme durress that you normally don't get into in the
first place.
Java used to have a lot of GC problems until they improved their
garbage collector and it became a non issue.
Of all the languages out there that are even remotely popular,
_javascript_s realtime behavior is by far the worst. Its a far cry even
from Actionscript.

> However, as Ken said -- there's no point in chasing imagined or theoretical
> performance issues.  It should be simple to write a real-world testcase that
> demonstrates any GC problems with using subarrays for arguments; then it can
> be looked at and see what's going on.  Otherwise, we're just talking theory.
This is not some hypothetical/theoretical/naval gazing issue. This is
a real and present issue that deeply influences how we all write code
in JS for realtime apps. I've already reported on this issue in
multiple bug trackers. For your perusal I've also produced 3 new test
cases, enjoy!

// Linux Chrome 15: [runtime: 62.77s] gc'ed 135ms, good frames: 3646,
bad frames: 16
// Linux Chrome 16: [runtime: 59.20s] gc'ed 125ms, good frames: 3390,
bad frames: 16
// Linux Firefox 8: only problems on unfocus etc.
// Linux Firefox 9: no problem

// Linux Chrome 15: [runtime: 60.42s] gc'ed 186ms, good frames: 3098,
bad frames: 51
// Linux Chrome 16: [runtime: 60.26s] gc'ed 220ms, good frames: 2967,
bad frames: 50
// Linux Firefox 8: only problems on unfocus etc.
// Linux Firefox 9: no problem

// Linux Chrome 15: [runtime: 59.94s] gc'ed 122ms, good frames: 3452,
bad frames: 15
// Linux Chrome 16: [runtime: 59.94s] gc'ed 122ms, good frames: 3452,
bad frames: 15
// Linux Firefox 8: only problems on unfocus etc.
// Linux Firefox 9: no problem

This seems to point out that there is no need for a new form of bufferSubData, only some improvements needed in some browsers.

Perhaps browsers can improve, but there's no magic here and no such thing as a free lunch. Garbage collection tuning is a series of tradeoffs. A win on this use case will be a loss on other use cases.  No matter how good the GC is it can only support a finite amount of object allocations per frame without dropping them.  Requiring objects for every bufferSubData call eats into this budget.  Even if we managed to get a collector that could maintain 60fps without dropping frames on this bufferSubData benchmark on all hardware, the added garbage adds a lot of pressure to the rest of the system and removes headroom for objects needed elsewhere in the critical path.

I agree that the view-based API is much nicer, and I'm very sympathetic to the need to keep implementations and specs simple.  I think that having a view type that was a value type instead of an object would be ideal, but that's not possible in _javascript_.  I think that WebGL needs to fully embrace the fact that it's a _javascript_ API and deal with the restrictions that imposes.  We expect authors to put in lots of effort avoiding unnecessary object allocation in their draw loops, shouldn't we put forth the same effort in the API?

- James