Bonne nouvelle pour Mail^^

intéressante votre petite discussion ! Merci pour vos infos, ça donne vraiment envie de voir ce que tout ça va donner ! hihi

Eh bien vivement ce moment là ;)

Oui la différence est beaucoup plus grande, mais au risque de me répéter, ça fait partie des choses où Cocoa a des faiblesses, c'est-à-dire les traitements volumineux mais qui peuvent être géré directement en C si le besoin de performance est réellement pressant. Mais je peux te garantir une chose, c'est que Carbon est loin d'être indispensable et qu'il ne va pas faire long feu. Il reste encore deux trois trucs que Cocoa ne gère pas encore seul et une fois que ce sera fini, plus besoin de Carbon du tout.

Je viens d'essayer la même chose en Cocoa sur le même dossier: - Temps: 27s - CPU utilisé à 50% pendant toute l'opération - La taille n'est même pas exacte à cause des resource forks que NSFileManager ignore. Les résultats parlent d'eux-mêmes…

Voilà les sources: [URL=http://myfreefilehosting.com/f/b3ab241efb_0.04MB] FolderSize [/URL] Merci pour le lien ;)

@Helgrind: Pour commencer, ce n'est pas la taille qui pose problème mais le nombre de fichiers, ensuite, si je t'ai demandé de faire le programme en carbon, c'était pour pouvoir comparer, balancer "5,19 s" comme ça ne signifie rien... Sinon regarde ce lien : [URL=http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html]Performance Comparisons of Common Operations, Leopard Edition[/URL]

Temps pour calculer la taille de mon dossier System (3.9go): 5.19s. En plus NSFileManager ne prends pas en compte la taille de la resource fork…

@Helgrind: relis ce que j'ai dit, j'ai dit que pour la majorité des traitements, le fait que Objective-C soit plus lent (tout est relatif, regardez ce test : http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html ), n'influe en rien sur le bon déroulement du programme, et pour tout ce qui est traitement intensif comme par exemple des appels récursifs très longs, tu peux utiliser le C pour avoir les performances maximales, si vraiment t'en as besoin... @iMicrobe: oui Cocoa est meilleur en tout, la seule chose qui pourrait s'apparenter à un handicape, c'est la relative lenteur d'Objective-C, mais elle est tellement minime que ce n'est vraiment pas un problème. @Helgrind: si tu veux, fait un programme en Carbon qui va calculer la taille d'un dossier pour pouvoir vraiment comparer. Moi je l'ai déjà écrit en Cocoa...

Ah bon, le cocoa c'est plus lent ? J'ai toujours cru que c'était mieux en tout moi... ;)

L'obj-c n'est pas beaucoup plus lent, mais il l'est légèrement , c'est un fait. Il n'empêche qu'il y a beaucoup de choses qu'on ne peut pas faire avec Cocoa et qu'il faut utiliser Carbon. Juste un petit exemple: calculer la taille d'un dossier (ce qui implique de calculer récursivement la taille de tous ces fichiers et sous-dossiers). Essaie de faire ça en Cocoa puis en Carbon et compare la différence de vitesse.

@Helgrind: Euh, non Objective-C est loin d'être aussi lent et ça ne demande vraiment pas beaucoup d'effort pour le rendre aussi rapide. Surtout avec le runtime d'Apple qui est très performant. Pour les tâches du quotidien, c'est-à-dire des traitements qui n'ont pas de boucles qui font énormément de calculs, notamment graphique, la différence de performance entre Carbon et Cocoa est totalement invisible à l'oeil nu. Et justement pour ces boucles très intensives, tu peux très facilement utiliser du C pur dans ton Objective-C pour avoir des performances maximales, et encore ce n'est que rarement utile. Objective-C/Cocoa est très très loin d'être lent et de son côté Carbon est vieillissant, il est basé sur les mêmes concepts que les autres plateformes, il est volumineux et pas simple du tout, il est tout ce que rejette Apple depuis toujours. Sa seule raison d'exister c'est qu'il a aidé la transition Mac OS 9 / Mac OS X, et que Microsoft et Adobe les utilise toujours. Mais le fait qu'Apple recode tous ses logiciels Carbon en Cocoa est loin d'être une surprise, c'est prévu de longue date, et Carbon aurait déjà du être enterré à leur actuelle si les fabricants de logiciels tiers n'étaient pas réticents à passer à Cocoa. En tout cas, je suis très content, je me disais on entend pas beaucoup parler de Snow Leopard en ce moment...

@ pitoux : la « tronche du matou » (j'adore l'expression :D) est là pour montrer que Snow Leopard tire la langue (sa manière de faire un pied de nez) à tous ses détracteurs.

@Dravick: entre le C qui est un langage de haut niveau et l'assembleur, je crois qu'il y a un soupçon de différence… Certes ça demande plus de travail et de complexité, mais ça apporte surtout de bien meilleur performances. Et je pense que pour arriver à des performances équivalentes avec Cocoa, il faut encore bien plus de travail.

Excellent pour imageboot ! Je veux ! O:-)

"Quel est l'avantage de faire ça, puisque les api carbon sont plus rapides que cocoa?" Pour la même raison qu'on ne code plus d'apps GUI en assembleur, pourtant l'assembleur est plus rapide que l'ObjC. En utilisant Cocoa, Apple pourra assurément éviter une quantité de bugs s'étant infiltré dans le code de finder carbon, simplement parce que coder en carbon requiert plus de travail et de complexité, donc plus de bugs.

La taille ?

Quel est l'avantage de faire ça, puisque les api carbon sont plus rapides que cocoa?

j'ai rien compris, mais vu la tronche du matou .... c'est surement excellent :j