Discussion :

[pitango]

Bonjour,

Je voulais savoir ce que vous pensiez de la commande
SetProcessWorkingSetSize ?

Après avoir migrer un service de BDE en ADO, je me retrouve avec un problème de fuite mémoire .

Je suis en train d'analyser le problème, mais en faisant des recherches je suis tombé sur la commande suivante .
SetProcessWorkingSetSize(GetCurrentProcess, $ffffffff, $ffffffff)

Utilisé avec un timer. Elle permet de contenir la mémoire. Mais je ne comprends pas trop son fonctionnement, comme procède t-elle ? Et n'y a t'il aucun risque à l'utiliser ?

Merci pour vos réponses

A+

[Rayek]

Qu'est ce qui te fait croire à une fuite de mémoire ?

Utilises tu la création dynamique de composants ? Si oui, libères tu bien tous tes composants ?

Sinon, je ne suis pas sûr que cette fonction soit utile pour le moment, il y a bon nombre de chose à vérifier avant (utilisant moi-même ADO depuis un bon moment, je n'ai eu aucun problème de fuite de mémoire).

[pitango]

Bonjour Rayek,

Qu'est ce qui te fait croire à une fuite de mémoire ?

Simplement , je constate qu'àpres avoir migrer l' application, elle se met à prendre de plus en plus de mémoire physique, jusqu'à saturation (Il s'agit d'un service qui tourne en permanence), ce qui plombe ses performances.

Pour info, en une heure mon appli passe près 125000 open et près 260000 ExecSQL(Et plus de 85000 Transaction).

La même appli en BDE qui occupait entre 16 et 25 mo de mémoire. Et en ADO, elle croit de façon constante pour bloquer vers 260 mo (SQLServer prenant le reste), le serveur cible n'ayant que 320 mo de ram.

Le traitement qui prenait 1h en BDE , prends alors plus de 12 heures

En utilisant la commande
SetProcessWorkingSetSize(GetCurrentProcess, $ffffffff, $ffffffff)
toutes les 60 secondes, l'appli ne dépasse pas les 60 mo, et retrouve des performances correctes au alentour de 1h33 (comparé au 1h en BDE).

D'où mon intérrogation sur l'usage de cette commande, et les résultat obtenus.

Parallèlement, je recherche les failles dans le code (présentes déja dans la version BDE). J'ai déjà trouvé qu'àprès le traitement, plus de 4000 tadoquery créées dynamiquement qui n'étaient pas libérés. (C'était des query dynamique où les free avaient été oubliés dans certains cas) En corrigeant , j'ai pu gagner 11 minutes de traitement. Les recherches continuent.....

As tu d'autres pistes de recherches ?

J'ai apperçu des post , concernant les fuites mémoires et les ADO qui indiquaient de modifier TADOQuery.Destroy dans la VCL

Code :

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

1
2
3
4
5
6
7
8
9
10
 
destructor TADOQuery.Destroy; 
 begin 
 // we modified like this ==> 
    FreeAndNil(FSQL); 
 // we modified : end 
    inherited Destroy; 
 
//  FreeAndNil(FSQL); // original source code 
 end;

Qu'en penses tu ?

Merci

A+

[Rayek]

Dans la plupart des cas, les problèmes de fuites de mémoire sont dû à une mauvaise libération d'un objet.
J'utilise régulièrement les composants Ado en création dynamique et l'utilisation du Free (avec D2005 Update 3) fonctionne parfaitement et je n'ai aucune perte (Des programmes tournent depuis plus de 6 mois sans que j'ai eu besoin à les redémarrer et la mémoire occille entre + ou - 300ko).

Sinon les composants Ado sont légèrement plus lent que le BDE (Surtout du au fait qu'on passe par une couche supplémentaire) mais ils sont 100 fois plus souple à utiliser et ne sont pas obsolète.

[pitango]

Dans la plupart des cas, les problèmes de fuites de mémoire sont dû à une mauvaise libération d'un objet

Tout à fait d'accord, je suis à leur recherche......

Pour l'utlisation du free, il est possible que le problème ait été corrigé en sur la version D2005.

Sinon les composants Ado sont légèrement plus lent que le BDE

C'est ce je constate aussi, mais coté utilisateur , c'est difficile à comprendre.

Mais j'interroge toujours sur cette commande SetProcessWorkingSetSize, qui en attendant de nettoyer le code, me rend bien service.

A+

[hmhm12]

salut,
personnellement, j ai migre plusieurs application écrit en BDE vers ADO, mais
la solution que j ai fait est la suivante;

chaque fois que j ai le temps , je change les BDETable en ADOTABLE
et BDEQuery en ADEQuery, et bien sur je change quelques lignes dans le programme.

le programme marche malgré que tu as des mélanges, c est logique.

[pitango]

Bonjour hmhm12,

Je n'ai pas trop compris où tu voulais en venir.

Concernant la migration à proprement dit, évidemment, une fois temriné il n' y a plus d'accès à l'unit DBTABLES, donc plus de ttable et tquery (BDE).

Ma question porte surtout sur l'usage de la commande :

SetProcessWorkingSetSize

Merci

A+

[Trulane]

salut Pitango,

Je crois que ce qu'ils veulent dire c'est qu'une migration de BDE vers ADO n'a normalement pas besoin de l'utilisation de SetProcessWorkingSetSize.

Bon courage pour tes recherches de fuites.

[pitango]

Trulane,

Pour la commande SetProcessWorkingSetSize, c'était juste pour en comprendre les fonctionnements et les problèmes que cela pouvait éventuellement apporter.

Elle me permet pour le moment (le temps de résoudre tous les problèmes de fuite), de contourner ce problème avec succès .

A+

Ps: Trulane,Regarde du coté de tes messages MP.