C VS DELPHI
Don0Choa
Messages postés
104
Date d'inscription
dimanche 29 octobre 2000
Statut
Membre
Dernière intervention
12 décembre 2005
-
30 juil. 2003 à 18:35
cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 - 21 sept. 2004 à 03:18
cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 - 21 sept. 2004 à 03:18
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/12680-c-vs-delphi
https://codes-sources.commentcamarche.net/source/12680-c-vs-delphi
21 sept. 2004 à 03:18
Non, pas la peine d'en faire une version assembleur...
17 août 2004 à 01:41
27 juin 2004 à 17:36
j'avait réalisé moi aussi un benchmark entre Borland Delphi7 et Borland Delphi 8 arctiteck... Le teste est une simple boucle avec un calcul banal ( genre addition koi ). Le code est le meme dans les deux application, ce qui change c'est que le programme généré par delphi 8 est deux fois plus long que celui de Delphi 7, j'ai toujours pas comprit et a vrai dire je m'attendai plutot a l'inverse... Quelq'un a t-il une explication ?
15 avril 2004 à 16:15
12 août 2003 à 08:31
les langages ont des buts différents, et je doute qu'en C tu puisses aussi aisément créer des menus, boutons, labels....
mais là c pas la guerre, c'est pour faire avancer ! ça permet de montrer que les inttostr et inverse ralentissent énormément le schmilblick... et d'autres trucs comme ça, donc c'est constructif !
6 août 2003 à 09:26
Quand à la syntaxe du C, j'étais pareil au début, mais j'ai été contraint d'y passer et je m'y suis donc fait au point de trouver un listing de Delphi assez fouillis, mdr :)
Pour les performances il n'est pas vraiment utile de passer par l'assembleur si on peut l'éviter, car çà c'est vraiment un langage difficile à relire, je pense que tu seras d'accord avec moi sur ce point (même si une procédure débutant par "asm", çà impressionne toujours, lol)
En l'occurence, le seul avantage que je pourrais reconnaitre au C après ce (léger) comparatif, c'est la taille ridiculement petite du code généré, et la gratuité de son compilateur... Car si j'ai payé ma license de Delphi 4 en mon temps, je n'ai plus tellement d'argent à dépenser dans un simple loisir, le matériel coute bien assez cher comme çà ;)
1 août 2003 à 20:26
Bon que se sois clair,
ce n'est pas le langage qu fais l'application, c'est le dèveloppeur qui la concois, personellement je n'aime pas le c, c'est uniquement parce que je hais sa syntaxe que je trouve trops peux lisible, c'est un chois, mais quand j'ai besoin d'un langage je l'utilise peut importe ses performances, si j'ai besoin de + vite, alors j'inclus d'une facon ou autre de l'assembleur...., c'est donc moi qui maitrise les performances, et débattre sur quel langage vas + vite que quel autre n'a pas rèellement de sens pour le développeur puisqu'il sais maitriser la machine, non ? .......
Bon Coding....
ManChesTer.
31 juil. 2003 à 13:47
toutefois pour la granulité, ca sert plus quand on crée une liste de records ou de class, parce qu en général c'est plus gros à allouer, mai bon on gagné un peu, mais c pas vraiment énorme
31 juil. 2003 à 13:41
- la granulité de la liste n'a aucun impact sur les temps d'accès
- trier la liste améliore les performances de 300% (toujours pour les temps d'accès), ce qui la met à égalité avec les listes chainées du C...
tout çà en une seule ligne modifiée, lol :
[...]
l := TStringList.Create;
l.Sorted := true;
QueryPerformanceCounter(x);
[...]
31 juil. 2003 à 13:14
Toutefois, je tiens à souligner que le code en C fait un hash MD5 là ou le Delphi se contente d'un IntToStr... J'avais mis cette conversion pour garder une certaine "équité" entre les languages, ne sachant pas faire de MD5 (le code C a été trouvé sur http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html - il doit bien y avoir un équivalent Delphi qui traine, mais je ne sais pas où)
31 juil. 2003 à 12:50
bien sur c'est parce que c'est des integer ke l'on enregistre sinon faut trouver autre chose
ah oui... en augmentant la granulité (réservation à l'avance de la mémoire) de la List en delphi, on augmente la vitesse du fait que l'on réaloue la mémoire moins souvent... un TList a une granulité variable et au mieux il prévoit je crois 64 cases du tableau d'avance donc environ 160 réalocation de mémoire à faire pendant le code...
31 juil. 2003 à 12:46
31 juil. 2003 à 12:31
Quand à la manière de coder les listes, tu as raison, j'avais "passé" arbres.c en Delphi, et l'exécution de ce code n'avait rien à envier aux listes chainées du C, donc bon... Delphi a de la ressource ;)
31 juil. 2003 à 11:33
parce ke en changeant 4 lignes de ton code le nouvo code fait parreil mais... au moins... 30x plus vite... lol...
31 juil. 2003 à 08:39
Delphi est un très bon language, ce n'est pas moi qui te dira le contraire :p Faudrait adapter ce bench à VB ou Java, histoire de rire ...
30 juil. 2003 à 18:35
En plus c'est à cause de toi que j'en fais... :)