Discussion :

[numeror]

Bonsoir

j'ai le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
      for i := 0 to WordsList.Count -1 do
        begin
          Item := WordsCountList.FindCaption(0, WordsList.Strings[i], false, false, false);
          if Item <> nil then
            begin
              e := StrToInt(Item.SubItems[0]);
              inc(e);
              Item.SubItems[0] := IntToStr(e);
              Item.SubItems[1] := FormatFloat('0.00', GetPercentage(e,WordsList.Count));
            end
          else
            begin
              Item := WordsCountList.Items.Add;
              Item.Caption := WordsList.Strings[i];
              Item.SubItems.Add('1');
              Item.SubItems.Add(FormatFloat('0.00', GetPercentage(1, WordsList.Count)));
            end;
        end;

,j'utilise ce code pour lister dans une listview les mots d'un texte que j'ai récupérer et mis dans une stringlist. et donc je regarde si l'entrée du stringlist en cours dans ma boucle est déjà dans le listview , si c'est le cas j'augmente le chiffre situe dans le subitems[0]. c'est boucle calcul aussi le pourcentage de présence d'un mot dans un texte.

Mon problème c'est que si mon texte de départ fait 3000 mots ou plus , ca bloque l'application , je voudrais savoir si cette boucle peut être optimise pour accepter un texte de 30000 mots sans bloquer l'application avec un temps de calcul de l'ordre de 1 a 2 secondes pas plus.

J'ai cherche , mais tout est utile dans cette modique boucle.

[numeror]

Excusez moi , j'ai oublié de vous mettre la procédure GetPercentage.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
function GetPercentage(Value: real; RefValue: real): Real;
begin
  Result := (Value * 100) / RefValue;
end;

Voila

[Paul TOTH]

TreeView n'est pas réputé pour sa rapidité.

il est préférable de passer à un VirtualTreeView ou a faire tes calculs en amont.

Est-ce que tous les mots sont dans WordsList ? Dans ce cas, tu commences par le trier WordsList.Sort() et tu repères alors les lignes qui se répètent pour déterminer leur nombre; tu n'as plus alors qu'à alimenter le TreeView

si tu veux conserver l'ordre de la liste tu peux passer par une seconde liste triée dans laquelle tu insères la chaîne et son Item associé : AddObject(Str, Item) afin de retrouve l'item pour la prochaine occurrence de cette chaîne.

[e-ric]

Salut,

Concernant le blocage de l'application, tu peux demander à ce que Windows reprenne un peu le contrôle des choses en appelant périodiquement ProcessMessages en fin de boucle:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
  if (i mod 100) = 0 then
    Application.ProcessMessages;

Ceci dit, ça ne résoudra pas tes problèmes de performances.

@+

[Jipété]

Mon problème c'est que si mon texte de départ fait 3000 mots ou plus, ça bloque l'application , je voudrais savoir si cette boucle peut être optimisée pour accepter un texte de 30000 mots sans bloquer l'application avec un temps de calcul de l'ordre de 1 à 2 secondes pas plus.

J'ai cherche , mais tout est utile dans cette modique boucle.

Me demande s'il ne lui manque pas le célébre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
      for i := 0 to WordsList.Count -1 do
        begin
          Application.ProcessMessages;
          // suite du code
        end;

Voir si le temps de calcul est impacté.
[EDIT] Ah, grillé à 5 minutes près par e-ric [/EDIT]

TreeView n'est pas réputé pour sa rapidité.

il est préférable de passer à un VirtualTreeView ou a faire tes calculs en amont. (...)

Euh, il est question de ListView, ici : ta remarque s'applique encore ?

[ShaiLeTroll]

Ne pas oublier aussi le BeginUpdate et EndUpdate sur les Items en cas d'un grand nombre d'ajout

Tu peux aussi ajouter une TProgressBar pour faire patientez l'utilisateur qui voyant que ça progresse accepte bien plus un petit délai

Des utilisateurs m'ont dit que certains programmes allait plus vite, ce qui était faux, ils étaient même plus lent à cause de nouvelle tache mais la TProgressBar les rassurait et leur donnait l'illusion d'efficacité !

Un simple TProgressBar.Refresh() permet de forcer l'affichage de la progression (parfois, il n'y en a pas besoin, je n'ai jamais bien compris ce qui faisait qu'une TProgressBar se dessinait sans soucis)
Alors que pour un TLabel utilise dans une longue boucle le Refresh ou plus brutal, le Application.ProcessMessages est obligatoire

[Paul TOTH]

Euh, il est question de ListView, ici : ta remarque s'applique encore ?

oups, pas faux mais oui ça reste une composant Windows qui est sollicité je suis a peu près certain qu'en passant par une StringList locale ça ira plus vite

[Andnotor]

oups, pas faux mais oui ça reste une composant Windows qui est sollicité je suis a peu près certain qu'en passant par une StringList locale ça ira plus vite

Je suis du même avis
Par définition, les tâches d'affichage sont très lentes.
De plus, ajouter un ProcessMessage ne va que gréver encore un peu plus les performances puisque le programme va perdre du temps à gérer des demandes sans rapport avec le travail en cours.

[guillemouze]

Personnellement, je te conseillerai d'utiliser un arbre lexical (ou lexicographique), que tu remplirai a partir de WordList (ou même que tu remplirai à la place de WordList).
L'interet est que le parcours est tres efficace, et donc ta recherche de doublons, lorsque tu as 30000 mots, va prendre un certain temps dans ta stringlist, et sera instantané sur un arbre. Le listing de tous les mots est aussi tres rapide avec un parcours en profondeur (et peut en plus tre trié alphabetiquement).

Tu as un exemple d'arbre ici (avec en plus les notions de base des arbres plus haut dans la page).

[numeror]

Bonsoir, j'ai teste une listview ne descendant pas de la vcl, et c'est aussi long. Connaissez vous un compo plus rapide que le listview ayant un affichage similaire, en mode report.

Merci et bon week end