En parlant de performance quand tu dis que les fonctions consomment des performances, je trouve ça bien dommage, je ne sais pas si c'est un problème du compilateur ou de ton usage de celui-ci, mais l'inlining n'a rien de nouveau et si (dans les langages qui le permettent, je ne sais pas si c'est le cas de l'objective-C) on donne assez d'informations au compilateur, il devrait être capable d'inliner une méthode
Objective c fait du message send, donc pas possible a inliner (le receveur peut forwarder le message a qui il veut ou le mapper sur une autre methode qui lui appartient, c'est plutot pratique quand t'en as besoin).
En pratique, un message send dont l'IMP est dans le cache (cas typique quand t'appelle le message 50 fois par seconde comme sur un scroll) est grosso merdo pas loin d'un appel de fonction C.
Je peux fourrer tout ca dans une fonction C, mais c'est aussi malin que de faire des classes statiques en Java.
Et surtout, ça changera pas grand chose au fait que cette logique appartient a cette methode, n'a rien a faire en dehors et ca ne changera pas le fait que la logique est quand meme a commenter parce qu'elle n'est pas triviale. Casser le truc en fonction va juste rendre le code plus dur a lire, c'est tout.
Tu rates completement le point, ce qui est important dans ce cas c'est commenter l'intention et les bugfix qui ont mene a ce code. Que tu mettes le code avant la declaration de la fonction ou dans le body ne change pas grand chose au fait qu'il faut commenter pourquoi c'est comme ca et pas autrement, histoire de confirmer que c'est bien ce que le developeur voulait ecrire en premier lieu.
Ce qui est dommage c'est que tu te retrouve à viser les performances très (trop à mon avis) tôt dans le développement
Ben ouais, mais t'es marrant toi, j'ai 20ms par run loop, au dela je drop des frames, ce truc est un composant réutilisable donc on peut pas faire les gorets, vu que les gens qui vont l'utiliser vont se retrouver a instancier des vues depuis des .nibs qui vont prendre 5-10ms. Si c'est pour me retrouver avec des scrolls aussi poussif que sous android, je prefere repartir ecrire du code backend, c'est plus marrant.
J'ai profile mon truc avant de faire ce genre de choix…
Je suis tout de même surpris qu'il n'y ais pas de composant de haut niveau pour faire ça et que tu te retrouve à travailler sur des rectangles, mais c'est peut être une question de performance.
Il y en a un, c'est l'UIScrollView (mere de tous), l'UITableView (tres haute performance et robuste comme tout, mais layout purement vertical et avec certaines particularites), et maintenant l'UICollectionView, mais ca c'est iOS6 only. Le probleme est loin d'etre simple a resoudre proprement.
[^] # Re: /* commentaire ou documentation inline ? */
Posté par groumly . En réponse au journal To comment or not to comment. That is the question.. Évalué à 2.
Objective c fait du message send, donc pas possible a inliner (le receveur peut forwarder le message a qui il veut ou le mapper sur une autre methode qui lui appartient, c'est plutot pratique quand t'en as besoin).
En pratique, un message send dont l'IMP est dans le cache (cas typique quand t'appelle le message 50 fois par seconde comme sur un scroll) est grosso merdo pas loin d'un appel de fonction C.
Je peux fourrer tout ca dans une fonction C, mais c'est aussi malin que de faire des classes statiques en Java.
Et surtout, ça changera pas grand chose au fait que cette logique appartient a cette methode, n'a rien a faire en dehors et ca ne changera pas le fait que la logique est quand meme a commenter parce qu'elle n'est pas triviale. Casser le truc en fonction va juste rendre le code plus dur a lire, c'est tout.
Tu rates completement le point, ce qui est important dans ce cas c'est commenter l'intention et les bugfix qui ont mene a ce code. Que tu mettes le code avant la declaration de la fonction ou dans le body ne change pas grand chose au fait qu'il faut commenter pourquoi c'est comme ca et pas autrement, histoire de confirmer que c'est bien ce que le developeur voulait ecrire en premier lieu.
Ben ouais, mais t'es marrant toi, j'ai 20ms par run loop, au dela je drop des frames, ce truc est un composant réutilisable donc on peut pas faire les gorets, vu que les gens qui vont l'utiliser vont se retrouver a instancier des vues depuis des .nibs qui vont prendre 5-10ms. Si c'est pour me retrouver avec des scrolls aussi poussif que sous android, je prefere repartir ecrire du code backend, c'est plus marrant.
J'ai profile mon truc avant de faire ce genre de choix…
Il y en a un, c'est l'UIScrollView (mere de tous), l'UITableView (tres haute performance et robuste comme tout, mais layout purement vertical et avec certaines particularites), et maintenant l'UICollectionView, mais ca c'est iOS6 only. Le probleme est loin d'etre simple a resoudre proprement.