Discussion :

[TheGzD]

Salut !

Je suis face à un problème relativement simple à comprendre bien que je n'y trouve pas de réponse

Je me sers d'un CRichEditCtrl dont j'utilise les méthodes StreamIn et StreamOut.
Une fois que j'ai défini les callback (auquelles je fais référence dans la structure EDITSTEAM), le sytème y fait appel tout les 4ko de données.
Il utilise donc un buffer de 4ko (qui peut très certainement ne pas faire cette taille en fonction du système) et, bien que permettant d'avoir un tas qui ne mobilise pas trop de ressources, restreint ainsi un peu les perfs.

J'ai donc 2 questions simple :
Comment récupérer la taille du buffer couramment utilisé ?
Comment fixer la taille de ce buffer ?

Merci d'avance.

[bacelar]

Je ne suis pas sûr que ce buffer fasse partie intégrante de la mémoire conventionnel du programme. A vérifier, mais je pense que c'est plutôt un buffer du GDI qui est régulièrement envoyée.

[TheGzD]

Merci pour ta réponse et désolé de ne pas avoir répondu plus vite, mais j'étais quelque peu en vacances

Je ne suis pas sûr que ce buffer fasse partie intégrante de la mémoire conventionnel du programme. A vérifier, mais je pense que c'est plutôt un buffer du GDI qui est régulièrement envoyée.

C'est bien possible, mais ça ne répond pas plus aux questions que je me posais

[bacelar]

Le lien suivant (deuxième partie de page):
http://209.85.229.132/search?q=cache...&ct=clnk&gl=fr

montre quelques astuces d'utilisation de ce control.

[TheGzD]

Merci pour ton lien, mais personne n'y donne de possibilité pour augmenter la taille du buffer au delà de 4k par défaut.
Les seuls choses qui y sont conseillées sont déjà appliquées à mon code.

Ce que je voudrais c'est simplement pouvoir augmenter la taille du buffer pour faire moins d'appel au callback lié au streamin. En effet je dois allé insérer par la suite ces données dans un BDD, donc si je dois faire une requete tous les 4k on est pas rendu avec les contenus de plusieurs mo Actuellement je recréé un buffer par concaténation successive (dans le callback) que je ne transfert qu'apres une 100ene d'appel au callback : ça marche, mais il devrait y avoir plus propre et rapide tout en brassant moins d'air, non ?

[bacelar]

Cette réponse ? http://209.85.229.132/search?q=cache...&ct=clnk&gl=fr

Quelques secondes pour 1MB sur une machine de 2003 avec possibilité d'optimisation.

[TheGzD]

Cette réponse ? http://209.85.229.132/search?q=cache...&ct=clnk&gl=fr

Quelques secondes pour 1MB sur une machine de 2003 avec possibilité d'optimisation.

mon soucis c'est que je peux avoir plusieurs 10ène de MB ... ça donne au final des temps de réponse assez long et plus qu'insatisfaisants

Si quelqu'un a un solution quelle qu'elle soit je suis preneur.

[bacelar]

Faire les optimisations indiquées par le lien dans mon précédent post.
Découper le flux d'entré en plusieurs blocs, gérer la scrollbar et les transitions entre les blocs.
Utiliser d’autre control bien plus récent, quitte à faire de l’interop avec .NET.
Etc.

Quand on ne passe pas par la porte, on passe par la fenêtre, quitte à la transformer en porte fenêtre.

[TheGzD]

Héhé je comprends bien mais j'aimerai ne pas changer de techno ni même si possible passer à une autre version du contrôle.

Par contre concernant :

Découper le flux d'entré en plusieurs blocs, gérer la scrollbar et les transitions entre les blocs.

a-t-on bien lu les même posts ?

PS : au fait j'utilise un RichEdit 2

[TheGzD]

Après avoir encore une fois cherché je suis tombé sur la doc de la msdn : About Rich Edit Controls

En bas de la page on peut lire :

Timings with EM_STREAMIN show that big RTF files (around 1MB) load roughly 30 times faster with version 4.1, as compared to 3.0.

et moi je tourne en version 2

Bon je crois que je sais ce qu'il me reste à faire maintenant
Je ferai un retour pour préciser si ça a réglé mon problème, en tout cas merci pour l'aide

[TheGzD]

Après surcharge de la classe CRichEditCtrl pour charge maintenant la dll MSFTEDIT.DLL et donc passer au RichEdit 4.1, il s'avère que je n'ai rien gagné en terme de temps d'exécution.

J'ai même pu observer un truc assez dingue : le temps d'exécution du StreamIn augmente exponentiellement avec la taille du texte .
En clair charger 2 fichiers de 1 mo et plus rapide qu'un seul de 2 mo ...

De plus la vitesse de traitement est plus rapide sur la fin du texte (oui oui ...).
Voici une trace des temps d'exécution pour un fichier de 25-30 mo (on relève le temps que prend chaque itération de 4 ko) :

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
   => iteration n°1 (16 ms)
   => iteration n°2 (15 ms)
   => iteration n°3 (0 ms)
   => iteration n°4 (0 ms)
   => iteration n°5 (16 ms)
   => iteration n°6 (0 ms)
   => iteration n°7 (16 ms)
   => iteration n°8 (0 ms)
   => iteration n°9 (15 ms)
   => iteration n°10 (0 ms)
 
...
 
   => iteration n°3427 (0 ms)
   => iteration n°3428 (0 ms)
   => iteration n°3429 (0 ms)
   => iteration n°3430 (0 ms)
   => iteration n°3431 (15 ms)
   => iteration n°3432 (0 ms)
   => iteration n°3433 (0 ms)
   => iteration n°3434 (0 ms)
   => iteration n°3435 (16 ms)
   => iteration n°3436 (0 ms)
   => iteration n°3437 (0 ms)
   => iteration n°3438 (0 ms)
   => iteration n°3439 (0 ms)
 
...
 
   => iteration n°6528 (0 ms)
   => iteration n°6529 (0 ms)
   => iteration n°6530 (0 ms)
   => iteration n°6531 (0 ms)
   => iteration n°6532 (0 ms)
   => iteration n°6533 (0 ms)
   => iteration n°6534 (0 ms)
   => iteration n°6535 (0 ms)
   => iteration n°6536 (0 ms)
   => iteration n°6537 (0 ms)
   => iteration n°6538 (0 ms)
   => iteration n°6539 (0 ms)
   => iteration n°6540 (0 ms)
   => iteration n°6541 (0 ms)
   => iteration n°6542 (0 ms)
   => iteration n°6543 (0 ms)
   => iteration n°6544 (0 ms)
   => iteration n°6545 (0 ms)
   => iteration n°6546 (0 ms)
   => iteration n°6547 (0 ms)

on voit clairement que le temps moyen de traitement d'une boucle chute, alors que le contenu du RichEdit lui n'a pas de singularité particulière (il s'agit d'un texte que j'ai copié un certain nombre de fois dans le fichier afin d'atteindre la taille voulue).
Si ce temps d'exécution était impacté principalement par le type/contenu du texte, j'aurai alors un schéma qui se reproduirai (dans mon cas d'exemple), enfin il me semble

Autant vous le dire je commence un peu à désespérer , et je fini même par me demander si ces RicheEdit ne sont pas passablement buggués ...

Je vais essayer d'ouvrir un peu plus le RichEdit afin de surcharger éventuellement les éléments qui pourraient me permettre de passer outre ces limitations.
Je reste bien évidemment ouvert à toute suggestion.

PS : je ne crois pas l'avoir précisé, mais le texte que je charge est le retour d'une requête passée sur une bdd MySQL et est stockée dans un char * (ceci est fait avant le l'appel au StreamIn, et se passe rapidement avec succès) => tout est sensé se passer en RAM et donc être performant, même si au final je stocke temporairement 2 fois la taille du texte (1 dans le char *, l'autre dans le RichEdit en fin de StreamIn).

[TheGzD]

J'ai réussi à accélérer pas mal StreamIn en ne faisant plus appelle à strlen dans le callback qui lui est associée => temps de traitement divisé par 5-10 !!! (si ça intéresse quelqu'un je peux détailler plus).

Mes autres soucis sont, quant à eux, toujours d'actualité