Bug 1692648 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
To achieve bug 1687095, one of the solution is to add `Vector`/`ParserAtomsTable` variant of `CompilationStencil`, and store the initial stencil if that type into XDR encode associated with `ScriptSource`,
and merge/accumulate all delazifications into initial stencil,
and encode the single `CompilationStencil` into XDR buffer.
This will solve the `ScriptStencil` duplication, `ParserAtom` duplication,
and also reduce the time taken by decode+instantiate.

This will also help bug 1692577, by using `Vector`/`ParserAtomsTable` variant of `CompilationStencil` as the base class of `CompilationState`, and instantiate directly from it,
so that we can skip `CompilationState::finish` call.

The plan is:
  * Templatize `BaseCompilationStencil`/`CompilationStencil` for `Span`/`ParserAtomSpan types`
  * Add `Vector`/`ParserAtomsTable` variant of `BaseCompilationStencil`/`CompilationStencil`
  * Make `CompilationState` a subclass of the `Vector`/`ParserAtomsTable` variant of `CompilationStencil`
  * Accumulate all information into `CompilationStencil` from parser/emitter (don't store any info into final `CompilationStencil`)
  * Make `CompilationState::finish` copy/move all data from `Vector` variant to `Span` variant
  * Support instantiation from `Vector`/ParserAtomsTable` variant of `CompilationStencil`
  * for the case `CompilationStencil` doesn't escape compilation scope, do not call `CompilationState::finish` but instantiate from `CompilationState`
Revision 1 by
on 
To achieve bug 1687095, one of the solution is to add `Vector`/`ParserAtomsTable` variant of `CompilationStencil`, and store the initial stencil of that type into XDR encode associated with `ScriptSource`,
and merge/accumulate all delazifications into initial stencil,
and encode the single `CompilationStencil` into XDR buffer.
This will solve the `ScriptStencil` duplication, `ParserAtom` duplication,
and also reduce the time taken by decode+instantiate.

This will also help bug 1692577, by using `Vector`/`ParserAtomsTable` variant of `CompilationStencil` as the base class of `CompilationState`, and instantiate directly from it,
so that we can skip `CompilationState::finish` call.

The plan is:
  * Templatize `BaseCompilationStencil`/`CompilationStencil` for `Span`/`ParserAtomSpan types`
  * Add `Vector`/`ParserAtomsTable` variant of `BaseCompilationStencil`/`CompilationStencil`
  * Make `CompilationState` a subclass of the `Vector`/`ParserAtomsTable` variant of `CompilationStencil`
  * Accumulate all information into `CompilationStencil` from parser/emitter (don't store any info into final `CompilationStencil`)
  * Make `CompilationState::finish` copy/move all data from `Vector` variant to `Span` variant
  * Support instantiation from `Vector`/ParserAtomsTable` variant of `CompilationStencil`
  * for the case `CompilationStencil` doesn't escape compilation scope, do not call `CompilationState::finish` but instantiate from `CompilationState`
Revision 2 by
on 
To achieve bug 1687095, one of the solution is to add `Vector`/`ParserAtomsTable` variant of `CompilationStencil`, and store the initial stencil of that type into XDR encoder associated with `ScriptSource`,
and merge/accumulate all delazifications into the initial stencil,
and encode the single `CompilationStencil` into XDR buffer.

This will solve the `ScriptStencil` duplication, `ParserAtom` duplication,
and also reduce the time taken by decode+instantiate.

This will also help bug 1692577, by using `Vector`/`ParserAtomsTable` variant of `CompilationStencil` as the base class of `CompilationState`, and instantiate directly from it,
so that we can skip `CompilationState::finish` call.

The plan is:
  * Templatize `BaseCompilationStencil`/`CompilationStencil` for `Span`/`ParserAtomSpan types`
  * Add `Vector`/`ParserAtomsTable` variant of `BaseCompilationStencil`/`CompilationStencil`
  * Make `CompilationState` a subclass of the `Vector`/`ParserAtomsTable` variant of `CompilationStencil`
  * Accumulate all information into `CompilationStencil` from parser/emitter (don't store any info into final `CompilationStencil`)
  * Make `CompilationState::finish` copy/move all data from `Vector` variant to `Span` variant
  * Support instantiation from `Vector`/ParserAtomsTable` variant of `CompilationStencil`
  * for the case `CompilationStencil` doesn't escape compilation scope, do not call `CompilationState::finish` but instantiate from `CompilationState`
Revision 3 by
on 
To achieve bug 1687095, one of the solution is to add `Vector`/`ParserAtomsTable` variant of `CompilationStencil`, and store the initial stencil of that type into XDR encoder associated with `ScriptSource`,
and merge/accumulate all delazifications into the initial stencil,
and encode the single `CompilationStencil` into XDR buffer.

This will solve the `ScriptStencil` duplication, `ParserAtom` duplication,
and also reduce the time taken by decode+instantiate.

This will also help bug 1692577, by using `Vector`/`ParserAtomsTable` variant of `CompilationStencil` as the base class of `CompilationState`, and instantiate directly from it,
so that we can skip `CompilationState::finish` call.

The plan is:
  * Templatize `BaseCompilationStencil`/`CompilationStencil` for `Span`/`ParserAtomSpan` types
  * Add `Vector`/`ParserAtomsTable` variant of `BaseCompilationStencil`/`CompilationStencil`
  * Make `CompilationState` a subclass of the `Vector`/`ParserAtomsTable` variant of `CompilationStencil`
  * Accumulate all information into `CompilationStencil` from parser/emitter (don't store any info into final `CompilationStencil`)
  * Make `CompilationState::finish` copy/move all data from `Vector` variant to `Span` variant
  * Support instantiation from `Vector`/`ParserAtomsTable` variant of `CompilationStencil`
  * for the case `CompilationStencil` doesn't escape compilation scope, do not call `CompilationState::finish` but instantiate from `CompilationState`

Back to Bug 1692648 Comment 0