Optimize OptimizedPhpArrayDumper further

I've been poking at this and want to float an idea.

The current approach makes bare strings mean "service reference" and wraps literal strings in a {type: 'raw'} stdClass. What if we went the other way: prefix the references instead? So '@module_handler' is a service reference, '%cache_bins' is a parameter, and 'hello' is just a literal string, no wrapper needed.

Your approach eliminates stdClass wrappers on service references, but every literal string argument becomes a new stdClass object. So we trade one set of allocations for another. I believe the prefix approach could eliminate both.

I prototyped the prefix idea from #9 with the help of Claude Code and benchmarked it against longwave's latest MR. This builds on the great work longwave already did.

First, let me illustrate the encoding difference as it helps everyone understand it. Let's take module_handler as an example. This is a typical service with five arguments: one literal string, one parameter reference, and three service references.

Drupal main

Its dumped form looks like this (596 bytes):

'module_handler' => [
  'class' => 'Drupal\Core\Extension\ModuleHandler',
  'arguments' => stdClass {
    type: 'collection',
    value: [
      '/var/www/html',
      stdClass { type: 'parameter', name: 'container.modules' },
      stdClass { type: 'service', id: 'keyvalue', invalidBehavior: 1 },
      stdClass { type: 'service', id: 'callable_resolver', invalidBehavior: 1 },
      stdClass { type: 'service', id: 'cache.bootstrap', invalidBehavior: 1 },
    ],
  },
  'arguments_count' => 5,
]

Five stdClass allocations per container build for one service: one collection wrapper, one parameter wrapper, and one per service reference.

Longwave's latest MR

Longwave's latest MR flattens service references to bare strings and drops the collection wrapper (321 bytes):

'module_handler' => [
  'class' => 'Drupal\Core\Extension\ModuleHandler',
  'arguments' => [
    stdClass { type: 'raw', value: '/var/www/html' },
    stdClass { type: 'parameter', name: 'container.modules' },
    'keyvalue',
    'callable_resolver',
    'cache.bootstrap',
  ],
]

Two stdClass allocations remain: one wrapping the literal string /var/www/html (because bare strings now mean "service reference"), and one for the parameter reference.

Dries' alternative encoding

The prefix variant eliminates both of the remaining wrappers (216 bytes):

'module_handler' => [
  'class' => 'Drupal\Core\Extension\ModuleHandler',
  'arguments' => [
    '/var/www/html',
    '%container.modules',
    '@keyvalue',
    '@callable_resolver',
    '@cache.bootstrap',
  ],
]

Zero stdClass allocations. The literal string passes through unchanged with no prefix. The parameter reference uses a % prefix. Service references use an @ prefix. Every argument stays a bare scalar, with no heap allocation per reference.

Benchmark results

Size aside, the main advantage of my approach is that it's faster, which is ultimately what we're trying to optimize for. Across a full Drupal install with all core modules enabled, prefix encoding eliminates over a thousand additional stdClass allocations that longwave's MR still makes.

Using ContainerDumpSizeTest.php from #6, with all 72 core modules enabled:

┌────────────────────┬─────────────┬─────────────┬─────────────┬────────────────┬───────────────────┐
│       Metric       │ origin/main │  longwave   │   dries     │ dries vs main  │ dries vs longwave │
├────────────────────┼─────────────┼─────────────┼─────────────┼────────────────┼───────────────────┤
│ Total size         │ 726.2 KB    │ 475.7 KB    │ 405.0 KB    │ -44%           │ -15%              │
│ Services size      │ 577.5 KB    │ 327.2 KB    │ 256.5 KB    │ -56%           │ -22%              │
│ stdClass objects   │ 4,184       │ 1,298       │ 108         │ -97%           │ -92%              │
│ Unserialize ALL    │ 0.93 ms     │ 0.52 ms     │ 0.35 ms     │ -62%           │ -33%              │
│ Unserialize top 17 │ 0.26 ms     │ 0.25 ms     │ 0.11 ms     │ -58%           │ -56%              │
│ get() ALL          │ 7.00 ms     │ 4.96 ms     │ 4.54 ms     │ -35%           │ -8%               │
│ get() top 17       │ 0.92 ms     │ 0.96 ms     │ 0.71 ms     │ -23%           │ -26%              │
└────────────────────┴─────────────┴─────────────┴─────────────┴────────────────┴───────────────────┘

Only took a quick look at the prefix solution in https://git.drupalcode.org/project/drupal/-/merge_requests/15349, and it seems like it accounts for escaping raw strings starting with @ and & with @@ and &&, but not %? Seems like it makes sense to use the same double escaping of %% as https://symfony.com/doc/current/configuration.html#configuration-parameters?

Granted these are likely edge cases.

@godislate: We don't use @@/&& double-prefix escaping. For all three characters (@, &, %), literal strings that would collide with prefix encoding are wrapped in a stdClass with type => 'raw', which the resolver treats as literal values. For %, that is done by the str_contains block around line 380.

@dries: Oh, OK. I was just going off the new testPrefixedLiteralStringEscape method in OptimizedPhpArrayDumperTest, which has test cases for string literals starting with @ and &, but not %.