On Tue, Dec 17, 2013 at 6:54 PM, Ehsan Akhgari wrote:
>
> How does one write a memory reporter that captures data stored on more than
> just the main thread? In the case of Web Audio for example, some of our
> buffers live in another thread, and as far as I can see the memory reporter
> API is mo
First of all, sorry for neglecting that bug! And +1 on this suggestion.
How does one write a memory reporter that captures data stored on more
than just the main thread? In the case of Web Audio for example, some
of our buffers live in another thread, and as far as I can see the
memory repor
On Tue, Dec 17, 2013 at 2:55 PM, David Rajchenbach-Teller
wrote:
>
> Is it possible to write memory reporters for JS-implemented code?
It's possible. Some points about this...
- Memory used by the JS engine already has good coverage in the "explicit" tree.
- It's hard to measure the sizes of t
Generally, I like the idea.
Is it possible to write memory reporters for JS-implemented code?
Also, is it possible to write memory reporters for Chrome Worker code?
Cheers,
David
On 12/17/13 4:57 AM, Nicholas Nethercote wrote:
> So I want to propose something: if you're working on a change tha
On 12/16/2013 03:09 PM, Gregory Szorc wrote:
> Perhaps Reflect.parse() could grow a new option to expose "comment" nodes or
> could attach comment metadata to specific node types?
It's really not possible to do the latter. Comments don't appertain to
specific nodes at all. They're just random
5 matches
Mail list logo
