2010-11-11 20 views
0

Comme vous le savez, Cappuccino implémente le mécanisme d'envoi de Objective-C/Smalltalk pour envoyer des messages aux objets (~ appelez leurs méthodes) dans une méthode spéciale appelée objj_msgSend.Comparaison de vitesse de Cappuccinos obj_msgSend() vs JavaScript-appel normal disponible?

[someObject someMethodToInvocate: aParameter]; 

De toute évidence, cela introduit une surcharge et donc une perte de vitesse. Je voudrais savoir si quelqu'un peut fournir une comparaison rapide entre ce message Envoi et la façon normale d'exécuter une méthode JavaScript ...

someObject.someMethodToInvocate(aParameter); 
+2

Peut-être qu'il y a une différence, mais la question est: est-ce important? Il y a probablement plus de différences entre les différents moteurs javascript dans les navigateurs. Faites des profils pour voir où votre code passe le plus clair de son temps et voyez si vous pouvez l'optimiser. "Optimisation prématurée ..." – some

+0

C'est une question générale, alors oui, c'est important. Ce n'est pas une optimisation prématurée non plus, parce que je voudrais évaluer la faisabilité, pas optimiser un peu de code. D'autant plus que obj_msgSend est appelé très très très souvent. –

Répondre

1

objj_msgSend est pour mes tests simples de méthode pure appelant environ 2-2,5 fois plus lent qu'un appel direct.

C'est en fait assez bon, compte tenu des fonctionnalités avancées qu'il rend possible.

3

Dans vos commentaires, vous dites que vous vous demandez « en général » dans le contexte des applications Cappuccino. Dans ce cas, le test est simple: exécutez n'importe quelle application Cappuccino, telle que GitHub Issues, et jugez par vous-même si elle est lente ou non. Essayez de faire défiler dans la table principale, sélectionnez quelques entrées et ainsi de suite. Cela vous dira si Cappuccino est rapide ou lent 'en général' car objj_msgSend est largement utilisé dans n'importe quel cas d'utilisation que vous pouvez imaginer dans une application comme celle-ci.

Si vous pensez à quelque chose de plus spécifique après tout, notez que rien sur Cappuccino ne vous force à utiliser le passage de message. Tout comme dans Objective-C, vous pouvez toujours «tomber sur le métal» - du pur JavaScript dans ce cas - quand vous avez besoin de faire quelque chose de plus performant. Si vous avez une boucle serrée, et que vous n'avez pas besoin de la fonctionnalité supplémentaire fournie par objj_msgSend, appelez simplement les fonctions directement. Objective-J ne m'en voudra pas.

+0

En fait, j'ai dit "en général" et non dans le contexte des applications Cappuccino.J'ai essayé la plupart des exemples disponibles de Cappuccino, mais comme vous l'avez dit vous-même: vous pouvez toujours tomber sur le métal. Par conséquent, l'impact de rapidité d'objj_msgSend n'est pas vraiment évaluable. Puisque personne ne semble avoir de réponse à cette question, je vais devoir faire quelques repères moi-même. Merci quand même. –

-2

Cela arrive deux ans trop tard, mais c'est une question légèrement invalide (en aucun cas dire que c'est une mauvaise question). Il n'y a pas de raison de douter de la vitesse d'objj_msgSend, pas quand on suppose qu'il s'agit d'une fonctionnalité spécifique à Smalltalk/Obj-C/Obj-J.

Javascript a TOUJOURS eu cette capacité.

Recherche: l'appel() et appliquer() ... (une recherche rapide Google apportera des articles comme celui-ci ->http://vikasrao.wordpress.com/2011/06/09/javascripts-call-and-apply-methods/)

Il est le même problème avec jQuery/Prototype/etc .. ., ils sont tous bien et dandy et utile. Mais ils nuisent à la communauté du développement parce que tout le monde s'appuie sur ces cadres au lieu d'apprendre les caractéristiques du langage de base qui rendent toute langue utile. Faites-vous plaisir ainsi qu'à la communauté du développement et APPRENEZ VOS LANGUES, PAS DES CADRES. Si vous connaissez les langues que vous utilisez, les frameworks que vous utilisez ne sont pas pertinents, utilisez-les ou construisez-les vous-même, car à ce stade, vous devriez être capable de le faire.

Espoir qui est venu aussi utile et non condescendant, ce n'est pas mon intention. :)

+0

... maintenant que je me sens un peu stupide, en regardant votre titre, il dit 'vs appel'. Donc vous êtes au courant. Mon point est toujours valable, si vous êtes préoccupé par la vitesse de cette méthode, pourquoi ne pas simplement utiliser la fonctionnalité intégrée de lanaguage ... :) –

+0

Vous n'allez pas construire. Application de classe Cappuccino sans cadre comme le cappuccino. Les cadres ont de l'importance. – Me1000

+0

yay downvotes (sarcasme). Je vais juste ignorer que ma réponse n'est pas si différente que la plus haute ... En fait, il n'est pas difficile d'émuler Cocoa sans un cadre comme le cappuccino. La plupart des choses les plus utiles (AppKit/UIKit) peuvent être émulées avec quelques centaines de lignes de code bien écrites. Je sais, je l'ai fait. Le plus gros point est que vous construisez du contenu Web, ce n'est pas la même chose que le domaine d'application «normal». Capp est doux, mais il s'adresse à un monde différent de celui du web. Yay son MVC, mais vous perdez HTML/CSS, les parties les plus utiles d'un navigateur. –