pourquoi en cs on aau lieu d un getter classique ?Code:
2
3
Version imprimable
pourquoi en cs on aau lieu d un getter classique ?Code:
2
3
Qu'est ce que tu appelles un getter classique ?
parce que écrire
c'est plus sympa que d'écrireCode:
2
3
Code:
2
3
Il n'y a pas de différence dans le principe... Mais comme les "getter" et "setter", comme tu les appelles, sont des structures classiques qui permettent de gérer l'accès aux données, elles ont été intégrées dans C# de façon à être utilisées plus naturellement.
C'est quand même plus sympa sous cette forme, non ?
c'est clair que c'est plus sympa, plus leger et plus parlant...
et est ce aussi plus rapide ou a ce niveau il n'est pas question de grapiller du temps de calcul... je dis ca car la je suis en train d essayer de booster mon code...
Ce n'est pas dans cette direction qu'il te faut chercher alors :)Citation:
Envoyé par sayag
Regarde plutot dans les accès aux ressources externes (fichiers, bases de données).
A mon avis c'est exactement pareil ! :PCitation:
est ce aussi plus rapide ou a ce niveau il n'est pas question de grapiller du temps de calcul
A l'intérieur d'un get ou d'un set, on peut mettre un certain nombre d'instructions, pour faire un traitement des informations avant de renvoyer la bonne[*]. Le concept de "getter" ou de "setter" a tout simplement été intégrée à la syntaxe du C#, mais elle ne le rend ni plus ni moins efficace.
Je *crois* même qu'au niveau du code intermédiaire généré lors de la compilation les propriétés sont transformées en méthodes "classiques" GetMachin et SetMachin.
[*] (il est cependant fortement déconseillé d'y mettre des fonctions lourdes car l'utilisateur de ta classe s'attendra à un accès presque instantané ! pour tout traitement lourd, recourir aux bonnes vieilles méthodes GetLeTrucDifficileACalculer())
Non, c'est juste une question de visibilité et de performance de maintenance....
Ce n'est pas vraiment le langage qui boost le code, mais l'algo : notions très différentes ;)
Evidemment il est conseillé d'utiliser l'existant :
la biblio Math,
savoir utiliser les tableaux, colletions, generics et enumerator au bon moment
(tit article sympa sur Collection et Enumerator):
http://www.microsoft.com/france/msdn...llections.mspx
éviter de bourrer le GC (éviter les new à répétition dans les boucles) très important! le vidage du GC est une opération très lente : dans les applis graphiques c'est le point sensible...
éviter aussi les calculs à répétition (précalculer au maximum)
Bien sur, bosser en code unsafe est plus dangereux, mais c'est la que tu gagnera le plus de temps.
Après ya les pseudo ptits trucs du genre :
préférer le for au foreach, et préférer le downtozero ( --i) au uptoX (++i)
(détection de 0 toujours plus rapide : je suis resté longtemps sceptique, car une soustraction est plus longue qu'une addition, mais c'est vrai que la comparaison à zero a chaque cas ce fera plus vite qu'une comparaison entre deux entiers)
A oui, il parait que ++i est mieux que i++ car il n'affectera pas de variable temporaire pour effectuer l'addition (tu gagnes un cycle^^)
Enfin, rapelles toi que de toute façon comme tu es en dotNet, ces petits trucs là semble bien ridicule face au boulot de la machine virtuelle :D
Enfin, avant de chercher a optimiser le code, optimises d'abord l'algo...
Merci pour les comm, j'essaye de faire le max sur l'algo et ca rentre petit a petit, je me repere meme plutot bien dans mes "raccourcis d algo", je veux dire quand l algo devint tellement lifté que tu le reconnait plus... mais bonje ne suis pas n pro de l algo non plus...
Comment vous faites ?Citation:
Regarde plutot dans les accès aux ressources externes (fichiers, bases de données).
___________
En tous les cas merci beaucoup pour les conseils, je vais peut etre optimiser ca : http://hybe.fr/developpez/
Les accès externes : c'est ce qui flingue n'importe quel bon algo de traitement qui suit...
en gros toute tes entrées sorties sont des plaies, tous les accès disc dur sont une horreur.
Si tu peux te permettre, tu précharge tout, sinon il faut bien définir à quel moment tu risques d'accèder a une ressource externe, sans devoir etre pris de court et mettre en pause le traitement...
On dit qu'humainement, si Mr CPU, Mme MémoireCache, Mme RAM et MrDiscDuc discutent, ca donne un truc comme ça :
Mr CPU pose une question a Mme MemoireCache : elle réponds en 1 sec
Mr CPU pose une question à Mme RAM : elle réponds en 1 heure
Mr CPU pose une question à Mr DiscDur : il lui faut.. 1 an...
Ils doit bien exister des outils en c# pour tester la lenteur du code...
Sinon tu fais ton bourrin, et tu enregistres les DateTime.now avant et après tes méthodes de traitements, puis tu trace les plus lentes...
ok merci je vais essayer ca.
Sinon tout est préchargé, a priori.
A part des hasttable remplie par une instance de classe Client, que ma winForm relie 50 fois dans mon appli...
Je devrais peut etre la lire une fois a l initialisation héhé
J'ai essayé de remplir un tableau des elements d une hashTable au lieu de consulter celle ci 100 fois dans mon programme.
MAis du coup je consulte 100 fois le tableau.
J y ai juste gagné de ne pas declarer 100 fois un nouvel enumerateur... est mieux ?