YAML Parsing is 4x slower since we implemented "Drop PECL YAML library support in favor of only Symfony YAML"

Allow the option to revert back to the older + faster PECL php parser - possibly via a config or settings.php setting

It is, but not easily.

/**
 * Override the default yaml parser class.
 *
 * Provide a fully qualified class name here if you would like to provide an
 * alternate implementation YAML parser. The class must implement the
 * \Drupal\Component\Serialization\SerializationInterface interface.
 */
# $settings['yaml_parser_class'] = NULL;

The hard part is: The class must implement the \Drupal\Component\Serialization\SerializationInterface interface.

30 minutes sounds impossibly slow to me also! How large is the configuration you are testing with?

The yaml_parser_class setting is deprecated and there is no replacement. It can be removed safely from your settings.php

See https://www.drupal.org/node/3415489

I was wondering if it would be possible reinstate the original \Drupal\Component\Serialization\Yaml class, create a new service to decorate the current class. Basically, swap it.

See core.services.yml

serialization.yaml:
    class: Drupal\Component\Serialization\Yaml

There is discussion to bring back the yaml_parser_class setting which would let you change this again: #3485296: Regression: Deprecation of `yaml_parser_class` setting in 10.3 breaks sites < 11.0

However, we removed support for PECL because it does not support arbitrary application specific tags at parse time; all possible tags need to be declared in advance, but the Symfony parser does not need this. See #3108309-26: Support Yaml::PARSE_CUSTOM_TAGS in \Drupal\Component\Serialization\YamlSymfony::decode for discussion.

Adding related issue.

The question here should be what config read is not cached by FileCache?

Also are we talking about parsing a single 34 MB file or 34 MB of files? Also does the server have APCu installed - if not you'll get a massive performance boost by installing this.

APCu is not always enabled by default on the CLI, if that is the use-case.

APCu is not only not always enabled on the cli but it's not shared between cli processes so it'll have a very low or zero hit rate for something like config import.

Ran into the same issue on #3478621: Add filecache to OOP hook attribute parsing and I've opened #3486503: Add a persistent cache for file-based discovery based on FileCache to see if we can make it more robust.

Workaround: Fix of the issue https://www.drupal.org/project/drupal/issues/3485296 released in >= 10.3.8 and < 11 version allow to set $settings['yaml_parser_class'] = "YamlParserClass"; in settings.php. This is deprecated in >=10.3.X version and will be removed from 11.

@nilesh chhantbar that's not a fix for this issue - it's a delay of the problem till 11.x

@alexpott Yes, it's an option or workaround until 11.x. It's clear that we need a solid fix in 11.x. or the upcoming release of 10.X.

Am I right that as soon as #2951046 Allow parsing and writing PHP constants and enums in YAML files hits we can basically move this issue to "Closed (won't fix)"?

As performance enthusiast, I would choose performance here.
Also, implementing #2951046 issue means we are basically no longer using neither of YAML 1.1 or 1.2 standard

@holo96 yes.

I like performance too. But looking but any yaml parsing shouldn't really be a performance consideration. We should not be reading yaml as part of the live running of the site and we should minimise it on rebuilds to with file caching.

I still think we need #3486503: Add a persistent cache for file-based discovery based on FileCache so that cli rebuilds actually get a file cache hit (apcu, even if if it's enabled on cli, has a cache per-process), although it needs to be a completely new service rather than the current approach in the MR in there.

Another problem with PECL yaml parser is incompatibility with PHP 8.5 (NULL cannot be and array key but spec allows ~) and no viable perspective to support 1.2 spec.

So +1 to close as designed

I'll reach out to the developed, he's been quick to fix for new versions of PHP when contacted.

Filed upstream issue https://github.com/php/pecl-file_formats-yaml/issues/97