YAML Parsing is slower since we implemented https://www.drupal.org/project/drupal/issues/3205480

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?

Thanks mglaman,

I assume the PHP PECL Parser does not implement this class and so using that is not possible without a patch/update to this project https://github.com/php/pecl-file_formats-yaml and then rollout to the hosting platform?

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: 🐛 Regression: Deprecation of `yaml_parser_class` setting in 10.3 breaks sites < 11.0 Active

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.

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 📌 Add a filecache-backed attribute parser Active and I've opened 📌 Add a core FileCache implementation that is database-backed Active to see if we can make it more robust.

Fix of the issue https://www.drupal.org/project/drupal/issues/3485296 🐛 Regression: Deprecation of `yaml_parser_class` setting in 10.3 breaks sites < 11.0 Active released in >= 10.3.x 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.