Optimize parsing of literal bytes.

[rsmmr]

• Introduce UnsafeConstIterator for bytes instances.
• Optimize parsing of literal bytes.

[rsmmr]

@awelzel How does this look to you? It gets the runtime for your examples down quite a bit. There's still a difference between the cases, and I'm actually not fully sure where exactly that is coming from (hard to pin down), but it can't be the literal instantiation anymore.

[awelzel]

I'm actually not fully sure where exactly that is coming from (hard to pin down), but it can't be the literal instantiation anymore.

Staring at flamegraphs (flamegraph diffing is totally failing me :-( ), I believe It's from the return value of expectBytesLiteral. Now that this passes in a reference, the return literal needs to create a copy, including a potential allocation, while before it probably just moved out the literal that was provided.

Does expectBytesLiteral()` need a return value? I'm looking at the generated code and the return value isn't used, so maybe can just void it?

[rsmmr]

Does expectBytesLiteral()` need a return value? I'm looking at the generated code and the return value isn't used, so maybe can just void it?

Ah, good one, I actually did mean to get rid of that, but forgot. Let me try that.

[awelzel]

I sent you one more patch idea in DM, but not sure it's applicable: It looked like there's a non-productive assignment within the generated code.

--- a/spicy/toolchain/src/compiler/codegen/parsers/literals.cc
+++ b/spicy/toolchain/src/compiler/codegen/parsers/literals.cc
@@ -104,8 +104,6 @@ struct Visitor : public visitor::PreOrder {
                     pb()->parseError("unexpected data when consuming token", n->meta());
                     popBuilder();
 
-                    builder()->addAssign(lp->destination(n->type()->type()), literal);
-
                     pb()->consumeLookAhead();
                     popBuilder();

I continue to see a difference between the 3 cases, but I'll open a separate ticket. It's kind of weird.