Re: AudioNode GC rules

On Fri, Mar 22, 2013 at 2:54 PM, Kumar <srikumarks@gmail.com> wrote:

> If you limit the space, then you automatically limit the number of nodes
>> that are "kept around". One can assume an implementation won't spend time
>> processing nodes that aren't taking up space.
>
>
> Technically true, but there is a space-time trade-off here. A hundred
> buffer source nodes serving grains from the same audio buffer may hardly
> take up any space worth garbage collecting (100KB + audio buffer size
> tops?), but could add significant compute cost.
>

The point is that requiring space usage to be O(N) in the number of
non-finished nodes means that the implementation must, over time, reclaim
finished nodes and therefore not process them. Exactly how many finished
nodes can be outstanding and when they will be reclaimed is not something
we should spec.

I'd like to preserve the kind of performance you get in the current webkit
> implementation due to the "dynamic lifetime" aspect. I've triggered a
> thousand source node "grains" per sec on a macbook air with no problems. It
> would be a pity to water that down. The spec needs to be precise enough and
> to the right extent for UA implementors, and also be clear enough for a dev
> to write code that can be expected to behave consistently across UAs. An
> order of magnitude performance difference between two UAs on the same
> machine would be unacceptable if both are spec conformant and otherwise
> have efficient audio code.
>

The spec's current text says that an AudioNode shoud live "as long as there
are any references to it", which includes "a normal JavaScript reference
obeying normal garbage collection rules". Since every node must start with
a JS reference to it, the current spec text implies lifetime rules that are
already tied to JS GC performance.

Generally in Web specs we haven't tried to specify performance
characteristics and there have been lots of "order of magnitude performance
differences" that we have tolerated for a long time. The traditional way to
iron out performance differences is to have browsers compete on the
performance of realistic benchmarks and real applications, and that seems
to always work well enough.

However I think it does make sense to specify automatic reclamation of
nodes in some fairly abstract way, like I suggested above, to make it clear
to fastidious Web authors that they don't need to write code to manually
disconnect finished nodes.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]