🇷🇴Romania @Cracu

backward compatibility should include also a change in composer.json.
That should help upgrades from D10 to D11 in one go.

This error can be triggered even when a normalizer misses the arguments in .services.yml file.
e.g.

services:
  md_content.my_entity_normalizer:
    class: Drupal\md_content\Normalizer\MyEntityNormalizer
    tags:
      - { name: normalizer, priority: 101 }

code above will trigger that.
adding arguments part will resolve the problem.

services:
  md_content.my_entity_normalizer:
    class: Drupal\md_content\Normalizer\MyEntityNormalizer
    tags:
      - { name: normalizer, priority: 101 }
    arguments: ['@entity_type.manager', '@entity_type.repository', '@entity_field.manager']

I struggled with this thing for a while, and while this helped, I realized that I can do something similar with "view" filter from twig_tweak module.
That filter will extract a render array from provided field item that will look similar to what @sutharsan provided.
E.g. in a twig for a field that is a reference you can display a formatted long text like this:

{% for item in items %}
  <div>{{ item.content['#entity'].field_name.0|view }}</div>
{% endfor %}

I tried to import some nodes(foods) that had some fields handled via paragraphs (nutrients).

Each food had a category(taxonomy) and a field called nutrients that accepts multiple values and had 4 sub-fields (name- taxonomy, quantity - decimal, unit - list, variation - taxonomy).

Each food got around 30-40 nutrients covered.

So in the end, for each food imported there were around 20-30 entities created (ignoring categories, because they were added only once).

It seems that it needed 75 seconds to insert 2444 entities (100 foods and related categories (<50) and nutrients 2300)

I tried to optimize a bit the import, instead of using migrations, I used a custom approach and tried to use transactions to save multiple nodes at once.

Import transaction duration 14 seconds (mysql only)

I tried to identify what's slow in entire process, so here are some stats form EntityStorageBase::save():
doPreSave: 19s, doSave: 21s, postsave: 24s

total_insert_queries: 31530
total_select_queries: 16354

If I need to identify how insert queries were used, I can make some estimations that for each food node I got around 10 queries and for each paragraph around 12 queries (entity tables, fields tables, revisions tables).

so... 1000 queries for nodes and 27600 for paragraphs.

I think the best approach, for my use case at least, is to get rid of paragraph field for this content type and simply use a custom entity, that would lose the revision support for sub-field, but that is acceptable for "fixed" data like nutrients.

that would transform number of total insert queries to 2300 queries probably, So I would expect 10x faster times for Import transaction and most probably some improvements for the entire process.

The most optimistic estimation would be to have around 8 seconds for 100 foods with related data, which is still kind of slow in my opinion.