J’ai fait le même travail, mais avec des versions plus récentes des ORMs et sans la surcouche symfony. Les résultats sont plus ou moins les mêmes, mais en anglais:

http://propel.posterous.com/how-fast-is-propel-15

Mais effectivement, les temps de quelques requêtes ne sont pas forcément représentative de ce qui peux être utilisé en condition réelle.

J’ai opté pour doctrine depuis quelques semaines déjà. Mon choix a été surtout guidé par la puissance et la souplesse du langage DQL.

Je pense que c’est un choix de design qui permet d’impacter directement les performances (comme éviter N requêtes SQL de Propel lorsque l’on peut en faire générer une seule par Doctrine).

Quant aux perfromances globales des 2 frameworks, Propel 1.3 et Doctrine utilisent PDO qui est la véritable pierre angulaire à mon avis (et qui commence à être mature, même sur des archis répliquées… pas comme il y a un an…). Grâce au mécanisme de préparation de requêtes MySQL gère mieux son cache (et oui, « SELECT * FROM table » et « Select * from table » sont 2 requêtes différentes pour MySQL, notez la sensibilité à la casse (entres autres)).

Dans le registre du cache de MySQL il faut savoir aussi que si une table contient au moins 1 champs texte > 255 caractères alors les requêtes pour cette table ne seront JAMAIS cachées en RAM… et là… on ne parle pas de perte de l’ordre de 20 à 30% de performance entre 2 frameworks, mais plutôt de l’ordre de temps d’accès entre RAM et disque dur… plutôt à l’heure actuelle d’ordre d’échelle 100 à 1000 !

Je voulais donc juste ajouter ce préambule pour que tout le monde comprenne réalise que quelque soit leur choix, Doctrine ou Propel, les deux reposent sur des avancées majeures de php (si seulement php pouvait avoir autant la classe syntaxiquement que python… et python les perfs de php !).
Que le meilleur de Doctrine ou Propel gagne !