After measuring the impact of #286, #287, and #290 and seeing it to be
too modest. I decided to use a memory profiler, and it found "the good
stuff".

These changes had the largest impact on allocations and performance.
When linking inputs that come from descriptor protos (as opposed to
inputs that are compiled from sources and have ASTs), this resulted in
a 23% reduction in latency and 70% reduction in allocations.

This change features the following improvements:
1. `ast.NoSourceNode` now has a pointer receiver, so wrapping one in an
`ast.Node` interface value doesn't incur an allocation to put the value
on the heap. This also updates `parser.ParseResult` to refer to a single
`*ast.NoSourceNode` when it has no AST, instead of allocating one in
each call to get a node value. The `NoSourceNode`'s underlying type is
now `ast.FileInfo` so that it can be allocation-free, even for the
`NodeInfo` method (which previously was allocating a new `FileInfo` each
time).
3. Don't allocate a slice to hold the set of checked files for each
element being resolved. Instead, we allocate a single slice up front,
and re-use that throughout.
4. Don't pro-actively allocate strings that only are used for error
messages; instead defer construction of the change to the construction
of the error.

…cations (bufbuild#286)

This adds a lookup methods, which can be used to improve the efficiency
of a resolver that is based on a `linker.Files`: instead of O(n) to
query each file for an item, we can look the item up from the symbol
table and directly determine the file it is in.

To further aid efficiency, this adds some benchmarks and then optimizes
the `Symbols.getPackage` function so both symbol table construction and
lookup are more efficient. In particular, instead of `strings.Split`,
which must allocate a slice, we now use a new `nameEnumerator` type,
which can be used to iterate through name components without allocation.

(cherry picked from commit 792268a)

After measuring the impact of bufbuild#286, bufbuild#287, and bufbuild#290 and seeing it to be
too modest. I decided to use a memory profiler, and it found "the good
stuff".

These changes had the largest impact on allocations and performance.
When linking inputs that come from descriptor protos (as opposed to
inputs that are compiled from sources and have ASTs), this resulted in
a 23% reduction in latency and 70% reduction in allocations.

This change features the following improvements:
1. `ast.NoSourceNode` now has a pointer receiver, so wrapping one in an
`ast.Node` interface value doesn't incur an allocation to put the value
on the heap. This also updates `parser.ParseResult` to refer to a single
`*ast.NoSourceNode` when it has no AST, instead of allocating one in
each call to get a node value. The `NoSourceNode`'s underlying type is
now `ast.FileInfo` so that it can be allocation-free, even for the
`NodeInfo` method (which previously was allocating a new `FileInfo` each
time).
3. Don't allocate a slice to hold the set of checked files for each
element being resolved. Instead, we allocate a single slice up front,
and re-use that throughout.
4. Don't pro-actively allocate strings that only are used for error
messages; instead defer construction of the change to the construction
of the error.

(cherry picked from commit 016b009)

…cations (bufbuild#286)

This adds a lookup methods, which can be used to improve the efficiency
of a resolver that is based on a `linker.Files`: instead of O(n) to
query each file for an item, we can look the item up from the symbol
table and directly determine the file it is in.

To further aid efficiency, this adds some benchmarks and then optimizes
the `Symbols.getPackage` function so both symbol table construction and
lookup are more efficient. In particular, instead of `strings.Split`,
which must allocate a slice, we now use a new `nameEnumerator` type,
which can be used to iterate through name components without allocation.

(cherry picked from commit 792268a)

After measuring the impact of bufbuild#286, bufbuild#287, and bufbuild#290 and seeing it to be
too modest. I decided to use a memory profiler, and it found "the good
stuff".

These changes had the largest impact on allocations and performance.
When linking inputs that come from descriptor protos (as opposed to
inputs that are compiled from sources and have ASTs), this resulted in
a 23% reduction in latency and 70% reduction in allocations.

This change features the following improvements:
1. `ast.NoSourceNode` now has a pointer receiver, so wrapping one in an
`ast.Node` interface value doesn't incur an allocation to put the value
on the heap. This also updates `parser.ParseResult` to refer to a single
`*ast.NoSourceNode` when it has no AST, instead of allocating one in
each call to get a node value. The `NoSourceNode`'s underlying type is
now `ast.FileInfo` so that it can be allocation-free, even for the
`NodeInfo` method (which previously was allocating a new `FileInfo` each
time).
3. Don't allocate a slice to hold the set of checked files for each
element being resolved. Instead, we allocate a single slice up front,
and re-use that throughout.
4. Don't pro-actively allocate strings that only are used for error
messages; instead defer construction of the change to the construction
of the error.

(cherry picked from commit 016b009)