Chapitre II : Job-shop avec Transport et qualité de service : Job-shop avec Routing
5. Études numériques
aux extrémités des blocs de Grabowski. (Larabi, 2010) et (Lacomme et al., 2013) étendent ces recherches locales pour le Job-shop Scheduling Problem with Transport en prenant en compte les opérations de chargement et de livraison : si deux opérations successives de chargement et/ou livraison appartiennent au chemin critique, alors elles sont soit interverties, soit l’une des opérations est affectée à un autre véhicule. Leur proposition peut directement être appliquée au JSPR.
Le principe du GRAS×ELS est donné par l’Algorithme 4 (voir chapitre 1 pour plus de détail). Une solution initiale est crée aléatoirement (ligne 8). Cette solution est représentée dans l’espace de codage par un vecteur de Bierwirth et un vecteur d’affectation des véhicules aux opérations de transport (voir section 2.3) qui permettent d’obtenir un graphe disjonctif orienté. Ce graphe est évalué par la fonction TLH. Une recherche locale définie par (Lacomme et al., 2013) pour le JSPT est utilisée ensuite (ligne 9), elle utilise également la fonction TLH. L’ELS est exécutée (ligne 13) pour générer des voisins à la solution (voir chapitre 1). Chaque voisin est évalué par la fonction TLH.
Algorithme 4 : GRASP×ELS pour le JSPR
1. Sortie
2. ∗ : la meilleure solution 3. Entrée
4. : les données du problème 5. Début
6. | ∗ = ∅
7. | Pour = 1, … , Faire
8. | | = Phase de construction //(contient TLH)
9. | | = Recherche locale //(contient TLH)
10. | | Si ( ) < ( ∗) Alors 11. | | | = 12. | | FinSi 13. | | = ELS //(contient TLH) 14. | | Si ( ) < ( ∗) Alors 15. | | | = 16. | | FinSi 17. | FinPour 18. | Retourner ∗ 19. Fin
5. Études numériques
5.1. Présentations des instances et des études
5.1.1. Instances pour le Job-shop Scheduling Problem with Routing
À notre connaissance, aucune instance spécifiquement dédiée au Job-shop Scheduling Problem with Routing n'est disponible. Un nouvel ensemble d'instances est introduit et est basé sur les instances de (Bilge and Ulusoy, 1995) initialement établies pour l’ordonnancement simultané d’opérations-machines et d’opérations de transport dans les
FMS. Ces instances sont communément admises par la communauté scientifique comme le jeu de données de référence du JSPT avec deux véhicules de capacité unitaire.
Les instances de (Bilge and Ulusoy, 1995) sont composées de deux ensembles (appelés datasets) 1 et 2 : le premier comprend les instances avec un rapport entre le temps de transport et le temps de traitement supérieur à 0.25 ( / > 0.25) ce qui signifie que les processing times sont largement supérieurs en durée au temps de transport. Il s'agit d'instances à dominante ordonnancement. Le second ensemble (ou dataset) contient les instances avec / ≤ 0.25. Les instances du second dataset sont donc à dominante transport. Toutes ces instances sont générées en considérant 10 jobsets et 4 layouts et définissent l’ensemble (ou dataset) 1 avec 40 instances et l’ensemble 2 avec 42 instances. Les instances de 1 sont notées , où est le jobset utilisé et le layout considéré. Pour
l’ensemble 2, les instances sont nommées , où est un chiffre supplémentaire avec
une valeur de 0 si les temps de transport sont divisés par deux et les temps de traitement doublés ou une valeur de 1 si les temps de transport sont divisés par deux et les temps de traitement triplés.
Pour les instances de (Bilge and Ulusoy, 1995), les deux véhicules ont les mêmes temps de transport et ces temps de transport sont indépendants du véhicule et du chargement. Ces instances sont étendues pour des évaluations numériques avec une flotte de véhicules de capacité non unitaire. Dans ce cas, deux véhicules d'une capacité de deux jobs chacun sont considérés, et chaque job représente le même volume. Les gammes opératoires des jobs et les temps de transport sont identiques aux instances originelles.
5.1.2. GRASP×ELS pour le JSPT et le JSPR
L’objectif du JSPR est de minimiser le makespan et de maximiser la qualité de service en définissant ℎ ( ) = 1/ℎ ( ). Les deux critères sont ordonnés par une somme agrégée avec les coefficients ( ; ) modélisant l’importance relative du makespan et de la qualité de service. La fonction objectif est définie comme suit :
( ) = × ℎ ( ) + × ℎ ( )
Où :
: une solution du problème ;
ℎ ( ) = de la solution , c’est-à-dire le makespan de ;
ℎ ( ) = ( ) + ( ) + ( ), qui sont respectivement le Total Duration, le
Total Riding Time et le Total Waiting Time de la solution ; ℎ ( ) = 1/ℎ ( ) est la qualité de service de .
Grâce à la métaheuristique utilisée et à la fonction objectif ( ) = × ℎ ( ) +
× ℎ ( ), le GRASP×ELS proposé peut résoudre le Job-shop Scheduling Problem with
Transport (JSPT) (minimisation du makespan uniquement) et le Job-shop Scheduling Problem with Routing (JSPR) (minimisation du makespan et maximisation de la qualité de service).
Pour la résolution du JSPT, la fonction objectif est définie avec = 1 et = 0 correspondant donc à une évaluation des dates au plus tôt. L’algorithme codé est générique et
dans ce cas précis, il correspond simplement à la première étape de l’évaluation TLH et est donc équivalent à un algorithme de plus court chemin classique.
Deux approches différentes sont expérimentées pour résoudre le JSPR. La première approche est une approche intégrée, tandis que la seconde est une approche séquentielle : La fonction objectif de l’approche intégrée (JSPR intégré) est F = × ℎ ( ) + ×
ℎ ( ) où = 10 000 et = 1, l’évaluation TLH est utilisée à chaque itération de la métaheuristique.
Pour l’approche séquentielle (JSPR séquentiel), α = 1 et β = 0 dans la fonction objectif pendant le GRASP×ELS (cette étape est équivalente à la résolution du JSPT). Puis l’évaluation TLH est appliquée à la meilleure solution trouvée durant la résolution du JSPT, pour obtenir une solution du JSPR.
Toutes les instances et les solutions sont téléchargeables sur les pages web suivantes : http://fc.isima.fr/~gondran/researches.html et http://fc.isima.fr/~gondran/JSPT/tlh.html.
GRASPxELS : Minimisation du Makespan (TLH = algorithme de plus long
chemin)
GRASPxELS : Minimisation du Makespan (TLH = algorithme de plus long
chemin) GRASPxELS : Minimisation du Makespan Et Maximisation de la QoS Maximisation de la QoS Cmax Cmax Cmax QoS Cmax’= Cmax QoS Calcul de la QoS (sans maximisation) Cmax QoS JSPT + calcul de la QoS JSPR séquentiel JSPR intégré
Graphe disjonctif, orienté, acyclique, non-évalué Graphe disjonctif, orienté,
acyclique, et évalué (les st sont fixés)
Figure 34 Les différentes approches de résolution
La Figure 34 représente les trois approches utilisées pendant les études numériques. Suite à la résolution du JSPT, la QoS de la meilleure solution trouvée est calculée (mais non maximisée, les dates des opérations sont fixes) afin de comparer ce critère aux différentes approches.
5.1.3. Présentations des quatre études
Les évaluations numériques sont divisées en quatre études.
La première étude (section 5.2) concerne la capacité du GRASP×ELS à fournir des résultats comparables à la littérature pour résoudre le JSPT avec une flotte de véhicules de capacité unitaire. À notre connaissance, il n’existe pas d’article dans une revue proposant de résultats numériques pour le JSPT avec une flotte de véhicules de capacité non unitaire ou proposant d’étude portant sur la QoS.
La seconde étude (section 5.3) compare les résultats obtenus lors de la résolution du JSPT par le GRASP×ELS avec les résultats obtenus lors de la résolution du JSPR intégré, en termes de makespan et de QoS (Gondran et al., 2018a).
La troisième étude (section 5.4) est composée de deux évaluations numériques : la première porte sur l’ordre d’insertion des time-lag maximaux lors de l’évaluation TLH ; et la seconde évaluation numérique a pour objet la capacité de la fonction TLH à trouver rapidement des solutions de bonne qualité (par rapport à l'évaluation exacte du graphe à l'aide de la formulation linéaire et de CPLEX) dans des temps raisonnables (Gondran et al., 2018a).
La quatrième étude (section 5.5) porte sur une comparaison entre le JSPT, le JSPR intégré et le JSPR séquentiel pour des véhicules de capacité unitaire et de capacité non unitaire (Gondran et al., 2019).
Les études sont toutes effectuées dans les mêmes conditions, sous Windows 7 sur un ordinateur Intel Core i7-4790 3.60 GHz avec 16.0 Go de RAM, ce qui équivaut à 2671 MFlops selon Dongarra (http://www.roylongbottom.org.uk/linpackresults.htm).
L'évaluation TLH est incluse dans une métaheuristique GRASP×ELS, les deux sont implémentées en C++. Le nombre d'itérations du GRASP est de 200, le nombre d'itérations de l’ELS est de 60 et le nombre de voisins lors de l’ELS est de 30. Chaque étude est répétée cinq fois avec une séquence de nombres aléatoires différente à chaque réplication pour limiter l'influence de la part d’aléatoire sur les résultats.
5.1.4. Notations
Cette section introduit les notations qui sont utilisées pour présenter les résultats numériques.
ℎ, ( ) La meilleure solution trouvée pour l’instance , durant la réplication , pour le
critère ∈ { ; } ;
ℎ,∗( ) = min
∈{ ,…, } ℎ , ( ) : la meilleure solution trouvée pour l’instance durant les
réplications, pour le critère ∈ { ; } ;
ℎ, ( ) = avg
∈{ ,…, }
(ℎ, ( )) : la moyenne de la meilleure solution trouvée pour l’instance durant les réplications, pour le critère ∈ { ; } ;
ℎ ,∗( ) = avg
∈{ }
(ℎ,∗( )) : la moyenne des meilleures solutions trouvées pour les réplications des instances appartenant au ∈ { 1 ; 2}, pour le critère
∈ { ; } ;
ℎ , ( ) = avg
∈{ }
(ℎ, ( )) : la moyenne de la meilleure solution trouvée durant les
réplications des instances appartenant au ∈ { 1 ; 2}, pour le
critère ∈ { ; } ;
,∗( ) Le temps moyen normalisé pour trouver la meilleure solution , durant la meilleure réplication ∗ parmi les réplications, pour toutes les instances du dataset ∈ { 1 ; 2} ;
,∗( ) Le temps total normalisé de résolution pour la meilleure réplication ∗ parmi les réplications, pour toutes les instances du dataset ∈ { 1 ; 2} ;
, ( ) Le temps total normalisé pour trouver la meilleure solution durant les réplications, pour toutes les instances du dataset ∈ { 1 ; 2} ;
, ( ) Le temps total normalisé de résolution pour les réplications, pour toutes les instances du dataset ∈ { 1 ; 2} ;
ℎ, ( ) (de l’instance durant les réplications, et la borne inférieure
donnée par (Ulusoy et al., 1997), ,∗( ) = (ℎ ,∗( ) − )⁄ ;
,∗( ) =
∈{ }
( ,∗( )) : l’écart moyen de la meilleure réplication de toutes les instances du dataset ∈ { 1 ; 2} ;
, ( ) L’écart moyen pour les réplications pour toutes les instances du dataset ∈ { 1 ; 2} ;
∆,∗ L’écart entre le JSPT et le JSPR (intégré ou séquentiel) de la meilleure réplication ∗ de l’instance pour le critère ∈ { ; } ;
∆,∗ =
∈{ }
(∆,∗) est l’écart moyen ∆,∗ pour toutes les instances du dataset ∈ { 1 ; 2}.
5.2. Première étude : comparaison avec la littérature
À notre connaissance, dix-neuf approches avec des résultats numériques et utilisant les instances de (Bilge and Ulusoy, 1995) sont publiées pour le JSPT, pour une flotte de véhicules de capacité unitaire. Le Tableau 11 introduit ces méthodes et indique quels datasets ( 1 et/ou 2) sont utilisés pour tester chaque approche. Aucun article ne propose des résultats numériques pour le JSPT avec plusieurs véhicules de capacité non unitaire.
Tableau 11 Publications avec les instances de (Bilge and Ulusoy, 1995)
Méthode Dataset Dataset Capacité
unitaire
Capacité non unitaire
(Bilge and Ulusoy, 1995) STW X X X -
(Ulusoy et al., 1997) LB et UGA X X X -
(Abdelmaguid et al., 2004) AGA X X X -
(Reddy and Rao, 2006) PGA X X X -
(Deroussi et al., 2008) SALS X X -
(Subbaiah et al., 2009) SFHA X X X -
(Babu et al., 2010) DE X X X -
(Larabi, 2010) MA X X -
(Kumar et al., 2011) PDE X X X -
(Erol et al., 2012) MAS X X X -
(Zhang et al., 2012) GATS X X -
(Lacomme et al., 2013) MEMA X X -
(Zhang et al., 2014) MSB X X -
(Zheng et al., 2014) TS-SPMA X X X -
(Sahin et al., 2015) FMAS X X X -
(Umar et al., 2015) WA Seulement
layout : 1 et 2 X -
(Baruwa and Piera, 2016) ALS X X X -
(Nouri et al., 2016b) GATS+HM X X -
(Zheng et al., 2016) HRA X X X -
L’étude se focalise sur les cinq dernières publications du JSPT avec une flotte de véhicules de capacité unitaire. Ces cinq méthodes proposent de nombreuses nouvelles meilleures solutions et sont testées sur l’ensemble des instances des deux datasets, excepté pour l’approche proposée par (Umar et al., 2015) qui n’utilise que deux layouts et un dataset. Cette approche n’est donc pas prise en compte dans cette étude, car leurs résultats ne
concernent pas toutes les instances. Les résultats numériques des 19 méthodes sont disponibles sur la page web : http://fc.isima.fr/~gondran/JSPT/state_of_the_art.html.
Rappelons que (voir section 1.2), la méthode TS_SPMA est introduite par (Zheng et al., 2014) et consiste en un algorithme de type Tabu Search. (Sahin et al., 2015) décrivent une approche multiagents : le FMAS pour un ordonnancement dynamique avec des capacités de traitements souples, ils résolvent également une version statique du JSPT. La méthode ALS est proposée par (Baruwa and Piera, 2016) : un Anytime Layered Search basé sur un réseau de Petri coloré hybridé avec une heuristique. Le GATS+HM est introduit par (Nouri et al., 2016c) et est une approche basée sur un Clustered Holonic Multiagent Model. Enfin, HRA est une Hormone Regulation based Approach pour des ordonnancements dynamiques, cette méthode est proposée par (Zheng et al., 2016) et est également testée sur les instances en mode statique. Pour chaque méthode, les résultats en termes de solutions et temps de calcul fournis dans les articles sont résumés dans le Tableau 12.
Tableau 12 Résultats fournis par les méthodes récemment publiées
Méthode Dataset Dataset
Best Time Best Time
(Zheng et al., 2014) TS_SPMA × / × /
(Sahin et al., 2015) FMAS × / × /
(Baruwa and Piera, 2016) ALS × × / /
(Nouri et al., 2016b) GATS+HM × × / /
(Zheng et al., 2016) HRA × / × /
Légende × L’information est fournie
/ Pas d’information donnée
Afin d'assurer une étude comparative équitable des différentes méthodes publiées, le facteur de vitesse est calculé et est tiré d'articles de recherche antérieurs, y compris, mais non
limité à Dongarra, au site web dédié au benchmark
Linpack (http://www.roylongbottom.org.uk/linpackresults.htm) et au site : http://asteroidsathome.net/boinc/cpu_list.php
Les facteurs de vitesse sont présentés dans le Tableau 13, ce dernier livre également les informations disponibles sur l'ordinateur, puisque les performances MFlops ne sont pas les seules influences sur le temps CPU. Le système d'exploitation et le langage utilisé des articles publiés précédemment, sont également rapportés dans cette table. Les temps de calcul normalisés des méthodes sont calculés à partir des temps de calcul présentés dans la publication originale multipliés par le facteur de vitesse.
Tableau 13 Performances relatives des ordinateurs
(Zheng et al., 2014) (Sahin et al., 2015) (Baruwa and Piera, 2016) (Nouri et al., 2016c) (Zheng et al., 2016) GRASP×ELS
Méthode TS_SPMA FMAS ALS GATS+HM HRA TLH
Nombre de répliques 5 / 10 / 5 Ordinateur Pentium IV 2.60 GHz / 2.60 GHz AMD Opteron 4 GB RAM Intel Core 2 Duo 2.10 GHz Intel Core 2 Duo 2.0 GHz
Intel Core i7-4790 3.60 GHz
OS Windows XP / / Windows 7 Windows 7
Langage C JACKTM et Java C++ Java Java C++ MFlops 3066 / 2400 2400 2400 2671 Facteur de vitesse 1.15 / 0.90 0.90 0.90 1
L’évaluation TLH proposée est générique et permet la résolution du Job-shop Scheduling Problem with Transport, qui est défini par une fonction objectif uniquement basée sur le makespan sans aucune considération pour la qualité de service. Dans ce cas la fonction objectif est définie par = 1 et = 0 dans l’évaluation TLH. Celle-ci correspond à un algorithme de plus long chemin de type Dijkstra.
Le Tableau 14 et le Tableau 15 présentent les résultats obtenus par le GRASP×ELS résolvant le JSPT avec une flotte de véhicules de capacité unitaire pour les deux datasets. L’écart moyen, ,∗( ), de la meilleure exécution est 26.8% pour le dataset 1 (Tableau 14) et 6.5% pour le dataset 2 (Tableau 15).
Pour le dataset 1 (Tableau 14), le GRASP×ELS concurrence les meilleures méthodes publiées, avec un écart par rapport à la borne inférieure de ,∗( ) = 26.8 %, ce qui est meilleur que HRA et FMAS. Le GATS+HM fournit un écart d'environ 20.6 % ce qui est légèrement inférieur à l'écart du GRASP×ELS avec un temps de calcul d'environ 12.08 secondes, soit quatre fois plus que le temps de calcul du GRASP×ELS, qui est d'environ 2.83 secondes. Similairement, l’ALS fournit un écart d'environ 25.5 %, mais un temps de calcul de l'échelle de 503.1 secondes en moyenne. Le TS_SPMA obtient des résultats d'environ 25.5 %, mais aucune étude comparative équitable sur le temps de calcul n'est possible.
Tableau 14 Performances du GRASP×ELS pour le JSPT, dataset 1 Dataset : / > . ,∗( ) % ,∗( ) (second) ,∗( ) (second) , ( ) % , ( ) (second) , ( ) (second) TS_SPMA 25.5 % / / / / / FMAS 44.9 % / / / / / ALS 25.5 % 503.1 3600 / / / GATS+HM 20.6 % 12.08 / / / / HRA 70.4 % / / / / / GRASP×ELS 26.8 % 2.83 10.50 27.4 % 2.10 10.51
La question typique qui se pose est de savoir si l'écart de solutions entre le GRASP×ELS et le GATS+HM pourrait être réduit en augmentant le nombre d'itérations. Plusieurs évaluations numériques ont été réalisées pour donner au GRASP×ELS le même temps de fonctionnement que l'algorithme GATS+HM, mais aucune amélioration
significative n'a été obtenue. Il y a donc probablement une convergence très et trop rapide du GRASP×ELS et les mécanismes de diversifications n'ont pas permis l'exploration d'une autre région de l'espace.
Pour le dataset 2 (Tableau 15), le GRASP×ELS fournit des résultats de bonne qualité avec une déviation moyenne de 6.5%, ce qui le place entre la méthode TS_SPMA (6.0%) et la méthode FMAS (7.2%). Mais aucune étude comparative n’est possible sur les temps de calcul, car aucune des méthodes ne donne leurs temps d’exécution.
Tableau 15 Performances du GRASP×ELS pour le JSPT, dataset 2
Dataset : / ≤ . ,∗( ) % ,∗( ) (second) ,∗( ) (second) , ( ) % , ( ) (second) , ( ) (second) TS_SPMA 6.0 % / / / / / FMAS 7.2 % / / / / / ALS / / / / / / GATS+HM / / / / / / HRA 11.3 % / / / / / GRASP×ELS 6.5 % 0.15 8.01 7.0 % 1.60 8.02
Cette première étude numérique nous amène à considérer que GRASP×ELS est adapté et bien paramétré pour résoudre le JSPT avec deux véhicules de capacité unitaire.
5.3. Deuxième étude : JSPT et JSPR intégré
La seconde étude est une comparaison des critères de makespan et de QoS entre le JSPT et le JSPR intégré. La résolution du JSPT ne prend pas en compte l’évaluation de la QoS, et correspond à une évaluation de type Dijkstra. Afin de comparer les méthodes de résolution, la QoS du JSPT est calculée sur la solution finale retournée par le GRASP×ELS. Il est important de noter que dans le cas du JSPT, la QoS est uniquement évaluée sans essayer de la maximiser : les dates de début des opérations sont des contraintes et ne peuvent pas être modifiées.
Cette étude est découpée en deux sections : une section (5.3.1) pour le cas d’une flotte de véhicules de capacité unitaire, et une section (5.3.2) pour le cas d’une flotte de véhicules de capacité non unitaire.
5.3.1. Capacité unitaire
Le Tableau 16 et le Tableau 17 présentent les résultats obtenus pour le JSPT (avec en plus une évaluation – sans modifier les dates des opérations – de la QoS) et le JSPR. La première colonne est le nom de l’instance, la seconde est la borne inférieure proposée par (Ulusoy et al., 1997). Les colonnes 3, 4, 5 et 6 concernent la résolution du JSPT par le
GRASP×ELS avec pour fonction objectif : = ℎ ( ) où ℎ ( ) est le makespan. Les
colonnes 7 à 12 se rapportent à la résolution du JSPR intégré (la fonction objectif est :
( ) = 10 000 × ℎ ( ) + 1 × ℎ ( )).
Les colonnes 3 et 7 donnent la valeur du makespan de la meilleure solution trouvée, durant les cinq réplications, respectivement par le JSPT et le JSPR intégré. Par exemple, pour
l’instance EX11 la meilleure solution a un makespan de 96 pour le JSPT et le JSPR. Les colonnes 4 et 9 sont la valeur du coût (cost) de la meilleure solution trouvée, durant les cinq réplications, respectivement par le JSPT et le JSPR intégré. Par exemple, pour l’instance EX12, le coût du JSPT est de 799 et le coût du JSPR est de 529. Les colonnes 5 et 11 sont les temps normalisés mis par le GRASP×ELS pour obtenir la meilleure solution, lors de la meilleure réplique, respectivement lors de la résolution du JSPT et du JSPR intégré. Les colonnes 6 et 12 sont les temps totaux normalisés de résolution par les deux méthodes.
Une valeur de ℎ,∗ ( ) (colonne 3) égale à ℎ ,∗ ( ) (colonne 7) signifie que la meilleure solution obtenue pour le JSPT et la meilleure solution obtenue pour le JSPR intégré ont un makespan équivalent. Par exemple pour l’instance EX41 (Tableau 16), ℎ,∗ ( ) = ℎ,∗ ( ) = 112, il en résulte un écart ∆,∗ nul. ∆,∗ est l’écart, en pourcentage, entre
ℎ,∗ ( ) et ℎ,∗ (y) avec ∆,∗ = (ℎ,∗ ( )-ℎ ,∗ ( ))/ℎ,∗ ( ). Pour l’instance
EX101 (Tableau 16), ∆,∗ = −0.68% signifie que le JSPT a obtenu un meilleur makespan
(ℎ,∗ ( ) = 148) que le JSPR intégré (ℎ ,∗ ( ) = 149). L’inverse se produit également, avec un ∆,∗ = 3.88% pour l’instance EX31 (Tableau 16) : le JSPR intégré a trouvé un meilleur makespan que le JSPT. Ceci est dû à l’impact du critère de QoS concernant le choix de la meilleure solution lors de la sélection du meilleur voisin au cours du GRASP×ELS, impliquant un parcours de l’espace de recherche différent.
La valeur moyenne des ∆,∗ est ∆,∗ = 0.16% pour le dataset 1 (Tableau 16) et ∆,∗ = 0.00% pour le dataset 2 (Tableau 17). Un écart de 0.16% signifie que le makespan moyen trouvé durant la résolution du JSPR intégré est meilleur que le makespan moyen trouvé lors de la résolution du JSPT. Cet écart résulte d’une meilleure diversification durant le GRASP×ELS. Un écart de 0% signifie que les deux méthodes ont des solutions avec un makespan équivalent.
.∗ est le temps mis par le GRASP×ELS pour trouver la meilleure solution tandis que
.∗ est le temps total d’exécution du GRASP×ELS. Par exemple, pour l’instance EX21 (Tableau 16), le temps pour trouver la meilleure solution pour le JSPT est de 1.94 seconde, et le temps total de résolution du JSPT est de 8.72 secondes. Le temps que requiert le GRASP×ELS pour fournir la meilleure solution est de 11.40 secondes (soit quasiment 5 fois plus long que le JSPT) et le temps total est de 19.93 secondes (soit 2 fois plus long que le JSPT).
La différence des temps d’exécution s’explique par le fait que le nombre d’évaluations du graphe disjonctif est beaucoup plus grand pour le JSPR (puisqu’une évaluation est réalisée à chaque insertion). Par ailleurs, pour le JSPT, le temps .∗ correspond à la première