En Panoramic, la seule solution consiste à créer un tableau trié et de chercher dans ce tableau par dichotomie.
Mais attention: le chargement d'un tableau de chaînes de caractères est horriblement long, bien plus lon que le chargement d'un objet LIST.
Tu connais aussi les objets LIST. Cela te semble trop long, ce que je veux bien croire. Est-ce que tu as mis l'attribut SORTED_ON sur la LIST en question ? Sûrement.
Une dernière possibilité: utiliser la nouvelle dll BDR.dll. Elle fait bien plus que ce que tu cherches, mais elle fait au moins cela: recherche rapide dans une liste triée en memoire, par dichotomie. Mais je ne sais pas du tout si les besoins en memoire pour 175000 éléments ne sont pas prohibitifs. A Essayer.
Pour créer, il faut utiliser:
BDRopen pour créer une base vide, sur disque et en memoire
une boucle de BDRadd pour créer les éléments (les données peuvent être vides)
BDRsave pour sauvegarder la base sur disque
BDRclose pour fermer la base
Pour utiliser: il faut utiliser:
BRDopen pour ouvrir la base existante
pour chaque recherche, BDRfindname pour trouver un nom
Il y a plein d'autres possibilités (recherche séquentielle en avant ou en arrière, filtrer les noms en fonctions de critères, ...). Tout est documenté dans BDR.chm.
Inconvénient de cette solution: c'est une DLL à part, pour le moment non intégrée à KGF.dll. Et pour utiliser KGF.dll, il faut fermer la base, puis décharger BDR.dll avant de charger KGF.dll. Sauf à utiliser les fonctions de l'ensemble "DynamicallyLoadDLL" qui sont:
LoadDLL, UnLoadDLL, TargetDLL,
CallDLL0, CallDLL1, CallDLL2, CallDLL3, CallDLL4, CallDLL5, CallDLL6
Avec cela, tu peux utiliser KGF.dll comme seule DLL connue de Panoramic, puis utiliser ces foncions pour ouvrir et utiliser une ou plusieurs DLLs supplémentaires, dont BDR.dll. C'est un peu plus complexe à utiliser...
Mais mon conseil, ce serait plutôt d'utiliser un système de dictionnaire personnalisé, adapté à tes besoins. Coupe ton gros fichier en x modules de taille comparable, et crée un fichier texte dont chaque ligne contient le dermier et dernier nom dans un des fichiers modulaires. C'est ce dernier que tu charges en mémoire dans un objet DLIST (non visible) avec attribut SORT_ON. Et tu cherchers, par dichotomie, le module censé contenir le mot que tu recherches, puis tu ouvres ce fichier module, tu le charges dans une autre DLIST avec SORT_ON, et tu cherches ton mot par dichotomie dans cette seconde DLIST.
Si tu découpes ta grosse liste en, disons 100 modules, tu obtiens une liste indexe de 100 lignes qui reste en permanence en mémoire, et 100 listes de 1750 lignes dont tu ne charges d'une seule pour chaque recherche. Et bien sûr, pour la recherche suivante, tu ne charges un autre module que si le mot recherché est censé être dans un autre module.
Ainsi, le chargement ponctuel est nettement amélioré. Cependant, en fonctionnement continu, tu as des chargements en permanence, et cela risque de dégrader les performances. C'est l'éternel conflit entre mémoire et performance.
Maintenant, tu as une autre possibilité. Crée un programme "serveur" en Panoramic, qui charge la liste totale une seule fois et la garde en mémoire. Ce programme ne fait rien à l'écran et reste actif en arrière-plan. Ton programme application communique avec de serveur par les routines IPC (Inter-Process-Communication) de KGF.dll, pour lui soumettre un mot à chercher. Le serveur le cherche et renvoie le résultat. Ce mécanisme est très simple à mettre en place, bien que cela ne corresponde pas forcément à la représentation mentale intuitive d'un programme fonctionnant de façon linéaire. Là, tu as un serveur qui fait une partie du boulot indépendamment. Mais cette communication entre programmes est très rapide.
Voilà. J'ai été un peu bavard, mais je voulais te donner une vue un peu plus exhaustive des possibilités et contraintes. J'espère que tu auras le courage de lire ce message jusqu'au bout...
Accueil 
Calendrier
