Cela me semble logique de résoudre un problème plus rapidement si les deux moitiés prennent moins de la moitié du travail de traitement de l'ensemble des données.
Ce n'est pas l'essence des algorithmes diviser pour régner. Habituellement, le fait est que les algorithmes ne peuvent pas "traiter l'ensemble du jeu de données". Au lieu de cela, il est divisé en éléments faciles à résoudre (comme le tri de deux nombres), puis résolus de manière triviale et les résultats recombinés de manière à obtenir une solution pour l'ensemble de données complet.
Mais pourquoi ne pas scinder le jeu de données en trois parties? Quatre? n?
Principalement parce que le diviser en plus de deux parties et la recombinaison de plus de deux résultats aboutit à une implémentation plus complexe mais ne modifie pas la caractéristique fondamentale (Big O) de l'algorithme - la différence est un facteur constant et peut entraîner un ralentissement si la division et la recombinaison de plus de 2 sous-ensembles crée une surcharge supplémentaire.
Par exemple, si vous effectuez un tri par fusion, vous devez maintenant trouver, dans la phase de recombinaison, le plus grand des 3 éléments pour chaque élément, ce qui nécessite 2 comparaisons au lieu de 1, de sorte que vous ferez globalement deux fois plus de comparaisons. . En échange, vous réduisez la profondeur de récursivité d'un facteur ln (2) / ln (3) == 0.63, ce qui vous donne 37% moins de swaps, mais 2 * 0.63 == 26% de comparaisons supplémentaires (et d'accès mémoire). Que cela soit bon ou mauvais dépend de ce qui coûte le plus cher dans votre matériel.
J'ai également vu de nombreuses références au tri rapide. Quand est-ce plus rapide?
Apparemment, une variante à double pivot de quicksort peut nécessiter le même nombre de comparaisons mais en moyenne 20% moins de conversions, ce qui en fait un gain net.
Qu'est-ce qui est utilisé dans la pratique?
De nos jours, presque personne ne programme ses propres algorithmes de tri; ils en utilisent un fourni par une bibliothèque. Par exemple, l' API Java 7 utilise en réalité le tri rapide à double pivot.
Les personnes qui programment leur propre algorithme de tri pour une raison quelconque auront tendance à s'en tenir à la simple variante à deux voies, car moins de risques d'erreurs sont 20% plus performants que la plupart du temps. Rappelez-vous: l’amélioration des performances la plus importante est de loin le moment où le code passe de "ne fonctionne pas" à "fonctionne".