Can you share the code you used for the benchmark to profile it?

The cannot share the models for the object graph currently. But the test is pretty straight forward:

<?php

use Doctrine\Common\Annotations\AnnotationReader;
use Doctrine\Common\Annotations\AnnotationRegistry;
use JMS\Serializer\SerializationContext;
use JMS\Serializer\SerializerBuilder;
use JMS\Serializer\SerializerInterface as JmsSerializerInterface;
use Symfony\Component\Serializer\Encoder\JsonEncoder;
use Symfony\Component\Serializer\Mapping\Factory\ClassMetadataFactory;
use Symfony\Component\Serializer\Mapping\Loader\AnnotationLoader;
use Symfony\Component\Serializer\NameConverter\CamelCaseToSnakeCaseNameConverter;
use Symfony\Component\Serializer\Normalizer\ObjectNormalizer;
use Symfony\Component\Serializer\Serializer;
use Symfony\Component\Serializer\SerializerInterface as SymfonySerializerInterface;

class SerializerComparisonTest extends \PHPUnit_Framework_TestCase
{
    /**
     * @var SymfonySerializerInterface
     */
    private $symfonySerializer;

    /**
     * @var JmsSerializerInterface
     */
    private $jmsSerializer;

    protected function setUp()
    {
        $classMetadataFactory = new ClassMetadataFactory(new AnnotationLoader(new AnnotationReader()));

        $callback = function ($dateTime) {
            return $dateTime instanceof \DateTime
                ? $dateTime->format(\DateTime::ISO8601)
                : '';
        };

        $encoders = array(new JsonEncoder());
        $normalizer = new ObjectNormalizer($classMetadataFactory, new CamelCaseToSnakeCaseNameConverter());
        $normalizer->setIgnoredAttributes(array('regions'));
        $normalizer->setCallbacks(
            array('startDate' => $callback, 'endDate' => $callback, 'validFrom' => $callback, 'validTo' => $callback, 'publicationDate' => $callback, 'updatedAt' => $callback)
        );

        $this->symfonySerializer = new Serializer([$normalizer], $encoders);

        AnnotationRegistry::registerLoader('class_exists');

        $this->jmsSerializer = SerializerBuilder::create()
            ->build();
    }

    public function testSymfonySerializer()
    {
        $productsExample = file_get_contents(__DIR__.'/products-example.json');
        $productCollection = $this->jmsSerializer->deserialize($productsExample, ProductCollection::class, 'json');

        for ($i = 0; $i < 100; $i++) {
            $this->symfonySerializer->serialize($productCollection, 'json', ['groups' => ['api']]);
        }

        file_put_contents(__DIR__ . '/products-example-symfony-serialized.json', $this->symfonySerializer->serialize($productCollection, 'json', ['groups' => ['api']]));
    }

    public function testJmsSerializer()
    {
        $productsExample = file_get_contents(__DIR__.'/products-example.json');
        $productCollection = $this->jmsSerializer->deserialize($productsExample, ProductCollection::class, 'json');

        for ($i = 0; $i < 100; $i++) {
            $this->jmsSerializer->serialize($productCollection, 'json', SerializationContext::create()->setGroups(['api']));
        }

        file_put_contents(__DIR__ . '/products-example-jms-serialized.json', $this->jmsSerializer->serialize($productCollection, 'json', SerializationContext::create()->setGroups(['api'])));
    }
}

Maybe you find an obvious error in the above test that explains the performance gap.
So if you have some models and data, you can easily do the test as well.

phpunit --filter testJmsSerializer
phpunit --filter testSymfonySerializer

Ok I've not used a profiler right now but there is obviously two things that slow down the Symfony Serializer here:

• You use Serialization groups without cache. The metadata extraction system is known to be very slow because it uses reflection. Using the provided Doctrine Cache adapter will instantly improve performance.
• You use the ObjectNormalizer. As it relies on the PropertyAccess component, it is very convenient but slow (in comparison, JMSSerializer use by default something similar to the PropertyNormalizer). @tucksaun @lyrixx and I discussed in the London Symfony Live of different ways to improve performance of the PropertyAccess component using a cache strategy but this is just some ideas for now. In the meantime when performance matter you can: use the GetSetMethodNormalizer or the PropertyNormalizer or inject in the ObjectNormalizer a custom implementation of the PropertyAccessInterface optimized according to the property access strategy of your project (e.g. don't rely on reflection and directly use a mutator method).

Your testSymfonySerializer calls $this->jmsSerializer->deserialize(, not sure if it's a small error or intentional.

@iltar Seems intentional for testing serialize method

@dunglas the metadata extraction caches it in memory anyway from what I've seen. So a cache wouldn't help in a single process test.

The ObjectNormalizer is really the slow part. I've changed it to the PropertyNormalizer and now the same test just takes 3.9 seconds.

But in general I've really hard time to replicate the behavior of the JMS serializer. So currently the serialization is broken and missing properties. Some findings:

• One needs to configure a callback for each DateTime property which is kinda strange. By default the serializer serializes the internal properties of the DateTime instance like lastErrors which is kinda silly.
• If you want to exclude properties, you can use $normalizer->setIgnoredAttributes(array('property'));. But what if the property you want to ignore is deep inside the object graph? So what if I want to exclude $object->subobject->property but do not want to exclude $object->property?
• Serializing null cannot easily be omitted. The symfony serializer does not have a built-in solution. One can use callbacks but only per attribute and not for everything.
• There seems to be a problem with inherited properties which are not serialized.

• I personally never use callbacks, I prefer to register a dedicated normalizer such as this one for \DateTime normalization in API Platform. I will open a PR to add this normalizer directly in Symfony.
• Use serialization groups to exclude properties anywhere in the graph (I never use the setIgnoredAttributes system too).
• You're right. You can use a custom normalizer having this behavior but if this is something common maybe can we add a builtin support for this in Symfony. IMO null are real values with a different meaning than no value at all. For instance API Platform ignores absent properties but not those with null values during the denormalization process. But in some case it probably can make sense to ignore such values.
• It should work (at least with the ObjectNormalizer), if it doesn't it's a bug. Do you have a failing test to reproduce this problem?

@dunglas The optimization you added reduced the above test case with ObjectNormalizer to half. From 14 seconds to 7 seconds. On PHP 7, the PropertyNormalizer took the same time as the JMS serializer (2.1 seconds). So even the simplest of all normalizers is not faster than the JMS serializer which offers alot more built-in features.

We found the inheritence problem I was talking about above. Our model implements IteratorAggregate and ArrayAccess which causes all other properties on the model to be ignored in the serialization. This is kinda unexpected.

@Tobion providing a profile of your script would help finding what should be optimized next. We cannot profile it ourselves, as you haven't provided a full reproducing case above

IMO, this issue should be reopened. I have profiled Symfony, JMS & Ivory serializer and here you can find a full reproductive case that you can easily profile: https://github.com/egeloen/ivory-serializer-benchmark

And the last benchmark result using caching and dev-master for all libraries: https://travis-ci.org/egeloen/ivory-serializer-benchmark/jobs/162590026

It results that Symfony is the slowest even if the cache is used.

Running your benchmark with last versions of Symfony components (in your benchmark you use 3.0@dev dev master was used) I get different results:

./bin/benchmark --iteration 1000

Ivory\Tests\Serializer\Benchmark\IvoryBenchmark | 0.00075191283226013
Ivory\Tests\Serializer\Benchmark\SymfonyBenchmark | 0.00084061002731323
Ivory\Tests\Serializer\Benchmark\JmsBenchmark | 0.00086667966842651

The Symfony Serializer is faster than JMSSerializer and slower than yours, but nothing significative (IMO) in a real production app.

Btw the cache of the PropertyAccess component isn't enabled (not sure if it will change something for a case like this one) and to be fair, you should use the GetSetMethodNormalizer instead of the ObjectNormalizer: the convenience of the ObjectNormalizer has a cost in term of performance, but it can be drastically improved by implementing #19330.

Using GetSetMethodNormalizer, the Symfony Serializer is the fastest one:

./bin/benchmark --iteration 1000

Ivory\Tests\Serializer\Benchmark\IvoryBenchmark | 0.00076944851875305
Ivory\Tests\Serializer\Benchmark\SymfonyBenchmark | 0.00067409038543701
Ivory\Tests\Serializer\Benchmark\JmsBenchmark | 0.00083684277534485

Thanks for the fast answer, I just update the benchmark according to your feedback