Discussion :

[WebPac]

Bonjour tout le monde.

Les objets que je fais dérivent tous de TComponent, hors hier j'ai fait des tests en créant 4 000 TComponent et en les détruisant en leur donnant un Owner tout simple, il a mis 5 secondes.

J'ai fait la même chose avec 400 000 TObject et il a mis une demi seconde.
J'ai essayé avec un TPersistent, idem, puis avec un TComponent en mettant nil comme Owner et il a mis 1 seconde toujours pour 400 000 exemplaires.

Donc je me demande si c'est vraiment utile de dériver d'un TComponent, quels en sont vraiment les utilités.

Car si c'est juste pour avoir un Owner, je peux très bien faire un TMyComponent qui dérive d'un TObject et j'y mets dedans une propriété Owner : TMyComponent, je peux aussi très bien rajouter un Tag : Integer; car je m'en sers parfois.

Merci de me donner vos avis sur la question et aussi quelle est la classe mère de vos objets pour qu'on puisse comparer non avis.

[Castagnems]

Voici un sujet qui semble très intéressant ... :-D

à suivre de près !

[tourlourou]

L'intérêt du Owner n'est-il pas de ne pas avoir à se soucier de la libération de l'objet => pas d'intérêt si le Free doit être manuel ???

[MHI]

Effectivement l'interet du TComponent est bien de ne pas se soucier de la libération (Delpfhi le gére tous seul) sauf s'il lui a été passé nil en paramétre bien en entendu. Mais il permet d'être placé dans la palette de composant et donc manipulable sur une fiche.

[Clorish]

Bon ... Petit cours sur la derivation des classes 8)

TComponent est la classe mere necessaire a l'implementation de classes qu'on souhaite installer dans la Toolbar et l'utiliser en mode Designe (ie conception) dans Delphi. LE Owner sert aussi a "Hierarchiser" les composants dans un programme, cad lui donner "un pere" responsable de sa destruction. Tres utile pour eviter de gerer nous meme la destruction des objets et d'avoir des fuites memoires.
Par contre toutes ces fonctionnalités ont un cout.

TPersistent est la calsse minimale de tout objet ayant une "persistance" dans le temsp. Je n'ai jamais bien compris la subtilité de cette fonctionnalité mais cela est necessaire pour implementer des types exportables dynamiquement depuis un Package.
Il permet aussi de pouvoir etre "enregistre" dans la memoire d'un programme, tres utile pour la creation dynamique d'objet et l'interrogation de classes (Voir GetClass)

TObject est l'ancetre minimal de toutes classes. Elle implemente le stricte minimum, d'ou sa rapidite de mise en oeuvre.

Pour moi, Tout objet simple, sans fonctionnalités particulieres, sont derives de TObjects (Classe de types Tris, recherche fichiers, record ammeloirees etc ....) dont la creation depasse rarement la portee de la procedure dans laquelel est est appelee ...

Je bascule en TPersistent quand j'ai un besoin d'exporter ces classes depuis un Package ou bien chose tres pratique : creer une methdoe generique de creation d'objets depuis des classes diverses (cf : Application.CreateForm)

Quand a TComponent, je m'en sert de plus en plus souvent, pour faciliter le parametrage des objets depuis l'inspecteur d'objet (Published), l'acces rapide depusi la toolbar, l'autodestruction des objets par leurs parents, etc .....

[WebPac]

Personnellement, je supprime tous les objets en appellant un Free, je ne laisse pas les composants le faire tout seul ainsi je peux mieux savoir ce qui est fait.

Je ne me sers pas de la propriété Components d'un TComponent qui liste tous les composants qu'il possède non plus car pas très pratique pour trouver rapidement le composant qu'on veut, j'ai au contraire fait des listes personnaliées qui me permettent d'accéder plus simplement et plus rapidement aux composants possédés.

A l'ouverture de l'application, il peut parfois créer plus de 5000 objets, si je gagne 5 secondes la dessus, c'est assez intéressant.

Je vais faire des tests pour voir si j'ai vraiment besoin de dériver de TComponent et je vous tiens au courant.

[Clorish]

En general, la cration depuis TComponent est bien sur la plus pratique dans bon nombre de cas .....

Maintenant si c'est une question deperformances .. c'ets un autre probleme.
A Cas precis necessite solutions precises.

Maintenant il faut voir aussi les composants dans leurs ensembles, cad avec des utilisations externes au programme. Dans ce cas tu risque d'avoir des soucis.

Bon il restera toujours la possibilité de creer un composants "Bis" qui derive de TComponent, et declare en interne (private) une versio ndu composant derivant de TObject, Tu redeclare toutes les props/Methdoes, en faisant la liaison entre celle ci et celles du composants interne ..

Mais bon je crois pas que cela soit considere comem tres "Propre" ^^

[WebPac]

Je viens de faire les premiers tests et en créant un assez grand nombre d'objet, on passe de 15.7 secondes à 11.6 secondes.
Je vais faire d'autres tests pour voir.

Je me dis que si pour le chargement on est plus rapide, peu-être pour l'utilisation on est plus rapide aussi.

J'ai en fait créé un TMyComponent dérivé d'un TPersistent qui possède un Tag et un FOwner qui est lui même un TMyComponent.

Il a fallu changer pas mal de choses dans le code pour que cela marche et j'avais certains objets comme des TListBox qui avaient un objet perso en Owner, j'ai donc dû bidouiller pour retomber sur mes pattes.

A savoir si je continue dans cette voie, je referrai certaines parties de codes, pour ne pas laisser des bidouilles qui sont pour faire les tests.

Il est vrai aussi que je pense qu'il serrait bien en fonction de l'importance de l'objet voir si on en fait un dérivé d'un TObject ou d'un TComponent.

Le problème que j'ai eu aussi est qu'il a fallu le changer pour tous les objets, car pour un objet dérivé d'un MyComponent, on voulait mettre en Owner un autre objet, il fallait que l'Owner soit lui même un MyComponent, ce qui implique à changer toutes les classes mères des objets.

[Clorish]

Je ne comprends pas trop ce que tu cherche a faire ....

Si tu continue dans cette voie, il me semble qu'il te faudra reprogrammer TOUS les composants dela VCL ... ca me parait enorme ....

Coment tu peut adapter un TLabel, TEdit, ... derivant de TPersistant directement sans passer par une reprogrammation complete ?!?

Quand a ce qui est de l'execution, laisse moi douter sur les differences de performances.
A la creation je comprends (histoire d'enregistrement dans les classes Owner etPArent) mais a l'execution je ne suis pas si sur.

De plus, peut etre qu'il y a une erreur de conception, a vouloir creer pres de 400.000 composants en sumultané en memoire (Tu as des ecrants 2000" ? :p )

Je plancherais plutot sur une reorganisation de la gestion des composants pour en limiter au max l'utilisation, notement a l'aide d'une gestion dynamique, plutot que la refonte du systeme de composants Borland pour les faire derriver de TPersistant et ganger quoi ... 5/6s au demmarage de l'applicatin ?!?

[WebPac]

En fait, le tests sur une plus grosse volumétrie ne donne plus les même résultats. On passe d'une différence de 4 secondes sur 16 secondes à une différence de 8 secondes sur 1 minute.
Les temps gagnés ne sont pas suffisant pour faire cette manipulation.

Non, je ne recrée pas des TListBox ou autres éléments visuels, mes objets ne sont pas des objets visuels, mais certains possèdent des éléments visuels comme un TPanel, un TListBox entre autre. Mes objets sont donc propriétaires d'objets visuels. Le fait de ne plus dériver d'un TComponent mais d'un TPersistent fait qu'ils ne peuvent plus être propriétaires, mais ce n'est pas forcément grave car j'ai de toute façon surchargé tous les destructeurs et ai mis dedans la destruction des objets qui sont la propriété du composant.

Pour être plus précis sur les objets que je crées, par exemple, on a une visualisation d'une table qui représente une table d'une BD, chaque item de la ListBox qui est un champ de la table possède un objet derrière mis dans le Data (pour l'élément visuel) ainsi, j'ai un objet Table non visuel qui possède les éléments visuels pour la dessiner et autant d'objet champ qu'il n'y a de champs dans la table.

Ce qui peut faire un assez grand nombre d'objets suivant le nombre de tables utilisées.

En fin, de compte, ce qu'il faut faire, c'est suivant la finalité de l'objet, le dériver d'un TComponent, d'un TPersistent ou d'un TObject.

[Clorish]

Tout cela est un peut confus pour moi .... ;p

Mais avant de passer a l'extreme (cad tout reprogrammer) j'ai pour habitude de chercher des solutions d'economies memoire en dynamisant encore plus les objets.

[WebPac]

en dynamisant encore plus les objets

Qu'entends-tu par là ?

En effet, je suis d'accord avec toi sur le fait qu'il ne faut pas tout reprogrammer.

Actuellement, je dois faire des algos assez complexes de tri et autre sur des enregistrements de sortie d'une requête sur BD.
Il faut que cela reste fort optimisé et j'ai du mal à connaitre ce qui est rapide et ce qui ne l'est pas en Delphi en fait.

Déjà, pour faciliter le travail, je vais créer un objet par enregistrement pour simplifier la tâche et décomposer le boulot, mais il ne faudrait pas que je gache les temps pour une connerie que j'aurrais oublié.
Cet objet, je le fais direct dérivé d'un TObject en fait pour ne pas perdre sur la création déjà.

[Clorish]

Si ton traitement de tri et/ou traitement des donnees est long, ce n'ets pas sur le temps decreation des objets que tu vas gagner le plus, mais sur l'optimisation des algos.

On sais tous que par exeple certains tris peuvent prendre 10s ou 10 siecles en fonction de la methode choisie sur le meme ensemble de donnees.

En ce qui concerne le fait de rendre les objets encore plus dynamique est par exemple ceci :
Tu as uen base avec 5 tables.
Tu creer un objet de type "Table" qui reprensente les tables.
Tu instancie un objet de ce type pour chaques tables.


La ou tu peut optimiser est dans l'instanciation que d'une ou 2 objet de tupes "Tables" que tu relie dynamiquement aux tables utilisee, au lieur d'avoir en permanances les 5 Tables chagees.

Comme parallele ca reviens au meme que de se debrouiller avec les 2 memoires des petites calculatrices M+, M- et la touche MR.

C'ets plus chaud a gerer mais tu peut y gagner (un tit peut) sur certains points.

[WebPac]

Pour les algos, merci, je suis en train de me renseigner sur les tris fusions qui sont si j'ai bien compris les plus rapides.

Pour ce qui est de rendre plus dynamique les objets, c'est prévu mais pour bien plus tard, quand tout serra fini et que j'aurrai le temps de remanier du vieux code pour l'améliorer.

Pour ce qui est de manier des objets pour tri ou pour tout autre chose, il est bon d'avoir des connaissances sur le fonctionnement des objets pour voir ce qui est bon et pas bon de faire.
Hier j'y ai mis mon nez dedans et maintenant je ne vais plus programmer de la même façon.
J'aimerais bien trouver une doc qui parle un peu de tout ça mais j'imagine que c'est encore bien utopique.

[Clorish]

Pour le tri, il me semblais que c'etait les Quicksort le plus rapide ?!?

[WebPac]

Oui en effet, mais finalement, je vais zapper ce problème car je vais utiliser la fonction Sort d'un TList qui fait du QuickSort.
Et juste faire un Compare personnalisé.

Pourquoi toujours réinventer la roue si d'autres l'on déjà fait et en mieux ?

[Clorish]

Pourquoi toujours réinventer la roue si d'autres l'on déjà fait et en mieux ?

C'est ce que je me tue a te dire depuis le debut du thread

[WebPac]

Loooooool.

Nan mais en fait, c'est pas que je veux tout le temps le faire, mais c'est que j'aime bien personnaliser les composants pour les adapter à mes besoins.