Vitesse et Langage de Table : TESTS.

La vitesse des traitement sous Paradox peut être dépendant du langage de table choisi. Voici quelques tests qui vous aideront à choisir vos options.

 

Test 1

Test sur 40200 enregistrements (ma table des codes postaux), avec un index secondaire sur "Ville + Invariant". Le test est le suivant :
            - ouverture de la table avec l'index secondaire ;
            - SetBatchOn() ;
            - scan de la table, un search().

Les tables ont été créées avec reprise, choix du langage de table, et rempplissage par une requête.

Chaque table a été préalablement restructurée, avec compactage.

Les durées sont en secondes.

Les tests sont lancés 13 fois de suite. Le résultat est la moyenne des 3 derniers (c'est à dire à partir de l'une stabilité du résultat).

 

Test 2

Avec la même table, mais sans aucun index, une requête (QBE) est réalisée pour compter les doublons de localités.

 

Résultats :

BDE     Pilote Natif - Paradox - Langdriver            Paradox 'Intl'
            Système - INIT - Langdriver                      Paradox 'Intl'

 

Test 1 :
1)         Paradox 'Ascii'            6 sec
2)         Paradox 'Intl'               6 sec
3)         'Ascii' Ansi                  6 sec

 

Test 2 :
            Paradox 'Ascii'  2 sec
            Paradox 'Intl'    7 sec
            'Ascii' ansi      2 sec

 

BDE     Pilote Natif - Paradox - Langdriver            'Ascii' Ansi
            Système - INIT - Langdriver                      'Ascii' Ansi

 

Test 1 :
1)         Paradox 'Ascii'            5 sec
2)         Paradox 'Intl'               5 sec
3)         'Ascii' Ansi                  4 sec

 

Test 2 :
            Paradox 'Ascii'  1 sec
            Paradox 'Intl'    13 sec
            'Ascii' ansi      1 sec

 

en plus :

remplissage (par QBE) :
            'Ascii' Ansi  =>  'Ascii' Ansi 429 sec
            'Ascii' Ansi  =>  Paradox 'Intl' 432 sec

 

Conclusion :
si vous faite beaucoup de requêtes (QBE), envisagez de sélectionner le bon langage de table.

 

Bonus

Si l'on remplace la mise à jour QBE par une mise à jour par tcursor, on passe de 429 sec à 32 sec !!!  Et cela sans influence notable due au langage de table.

P.s : si l'on encadre le nom des champs avec des guillemets ("), le script met 6 sec de plus.

QBE :

Query

c2.DB | Invariant | CodePostal | Localite |
      | _a        | _z         | _e       |

c1.DB  | Invariant | CodePostal | Localite |
Insert | _a        | _z         | _e       |

EndQuery

Script :

var
            dtd,dtf time
            tc,td tcursor
            nb longint
endvar
empty("C1.db")
tc.open("C2.db","VILLE")
td.open("C1.db","VILLE")
td.edit()
td.setBatchOn()
nb=0
dtd=time()
scan tc :
            td.insertAfterRecord()
            td.Invariant=tc.Invariant
            td.CodePostal=tc.CodePostal
            td.Localite=tc.Localite
            td.postRecord()
            td.unLockRecord()
            nb=nb+1
            if longint(nb/1000)*1000=nb then
                        message(nb)
            endif
endscan
dtf=time()
tc.close()
msginfo(string(dtd),string(dtf))

 

Rappel : le langage de table se paramètre à 3 endroits :

 

  • dans l'administrateur BDE :